How to set up LndHub on top of RaspiBolt ir RaspiBlitz?

The RaspiBlitz is running LND. So, when you look at https://github.com/BlueWallet/LndHub, you will find that you only need to install Redis and then you can set up LndHub.io as in their documentation:

git clone git@github.com:BlueWallet/LndHub.git
cd LndHub
npm i

Install bitcoind, lnd and redis. Edit config.js and set it up correctly. Copy admin.macaroon and tls.cert in root folder of LndHub.

You can do all of that via ssh on your RaspiBlitz.


Sending my Bitcoin cash using my private key

After trying a few more wallets I got one to do what I want :): http://electroncash.org/

Of course it had to wait until I had already posted my question...


Where do I find my bitcoins after buying from an ATM?

When you purchase bitcoins at an ATM, you have to provide a destination where they'll deliver the bitcoins. Recipient information is provided in form of addresses. The receipt shows an address to which the ATM delivered the bitcoins. As pointed out by other answers, the bitcoins were actually sent to that address.

The question is now, how did you provide the destination address for the purchase? Did you perhaps show a QR code from a wallet on your phone, or had a printed QR code that you got scanned by the ATM? The bitcoins would have been received to the corresponding wallet, e.g. on your phone if it was a mobile phone wallet.


Mining pools export this functionality via API's.

For example, poolin's API docs are here: https://btc.com/api-doc

Here's F2Pool's : https://www.f2pool.com/developer/api

And so forth.

The way aggregators add value is by compiling all this data from different pools into a neat user interface.


Bitcoin core has been stuck syncing to the network

The only answer I could come up with myself was to "unprune" the blockchain to force it to redownload. I then reactivated the "prune" feature and restarted the blockchain download. I think the block was corrupted - we'll see.


getblockcount is returning incorrect count

I get the error no such mempool transaction. Using block explorer, this transaction appears in block 277316.

Unless you're running with the -txindex command line option, or a txindex=1 line in your bitcoin.conf file, getrawtransaction only works for mempool transactions (not transactions already in the blockchain).

  I noticed that when I run bitcoin-cli getblockcount, I only get 180024, which was mined in 2012. Why am I getting such old data?

Presumably your bitcoind is still synchronizing with the network. This may take hours (or even days, on slow hardware).


How to attach an encrypted message to a payment transaction inside a contract?

I've asked this question in ardors slack developer channel and post it here for documentation. After a small dialog in which I detailed the occurring error with a small example contract I got an explanation with a working solution:

About the messageToEncrypt parameter, the problem is that when a transaction is submitted by a contract it is first generated without a secretPhrase then signed and broadcasted. This means that message cannot be encrypted when the transaction is generated.
Therefore to submit an encrypted message in your contract you need to encrypt it yourself using the technique in sample contract IgnisArdorRates line 94:

   // Encrypt the message
   EncryptedData encryptedData = context.getConfig().encryptTo(Account.getPublicKey(context.getSenderId()), Convert.toBytes(response.toJSONString(), true), true);

   // Send a message back to the user who requested the information
   SendMessageCall sendMessageCall = SendMessageCall.create(context.getChainOfTransaction().getId()).recipient(context.getSenderId()).
           encryptedMessageData(encryptedData.getData()).
           encryptedMessageNonce(encryptedData.getNonce()).
           encryptedMessageIsPrunable(true);
   return context.createTransaction(sendMessageCall);

I've adapted my example contract according to this answer and post it here to share the solution:

example contract:

package com.jelurida.ardor.contracts;

import nxt.account.Account;
import nxt.addons.AbstractContract;
import nxt.addons.JO;
import nxt.addons.TransactionContext;
import nxt.crypto.EncryptedData;
import nxt.http.callers.SendMoneyCall;
import nxt.http.responses.TransactionResponse;
import nxt.util.Convert;

public class TestContract extends AbstractContract {

    @Override
    public JO processTransaction(TransactionContext context) {
        TransactionResponse transaction = context.getTransaction();
        EncryptedData encryptedData = context.getConfig().encryptTo(Account.getPublicKey(context.getSenderId()), Convert.toBytes("test message", true), true);

        SendMoneyCall sendMoneyCall = SendMoneyCall.create(transaction.getChainId())
                .recipient(transaction.getSender())
                .amountNQT(transaction.getAmount())
                .encryptedMessageData(encryptedData.getData())
                .encryptedMessageNonce(encryptedData.getNonce())
                .encryptedMessageIsPrunable(true);

        return context.createTransaction(sendMoneyCall);
    }
}

unit test:

package com.jelurida.ardor.contracts;

import nxt.addons.JO;
import nxt.blockchain.Block;
import nxt.blockchain.ChildTransaction;
import nxt.blockchain.FxtTransaction;
import nxt.messaging.PrunableEncryptedMessageAppendix;
import nxt.util.Convert;
import org.junit.Assert;
import org.junit.Test;

import static nxt.blockchain.ChildChain.IGNIS;

public class TestContractTest extends AbstractContractTest {

    @Test
    public void encryptedMessageTest() {
        String contractName = ContractTestHelper.deployContract(TestContract.class);

        JO messageJson = new JO();
        messageJson.put("contract", contractName);
        String message = messageJson.toJSONString();
        ContractTestHelper.bobPaysContract(message, IGNIS);
        generateBlock();

        Block lastBlock = getLastBlock();
        boolean transactionFound = false;
        for (FxtTransaction transaction : lastBlock.getFxtTransactions()) {
            for (ChildTransaction childTransaction : transaction.getSortedChildTransactions()) {

                transactionFound = true;
                Assert.assertEquals("test message", extractMessage(childTransaction));

            }
        }
        Assert.assertTrue(transactionFound);
    }

    private String extractMessage(ChildTransaction transaction) {
        PrunableEncryptedMessageAppendix appendix = (PrunableEncryptedMessageAppendix) transaction.getAppendages().stream().filter(a -> a instanceof PrunableEncryptedMessageAppendix).findFirst().orElse(null);
        byte[] compressedData = appendix.getEncryptedData().decrypt(BOB.getSecretPhrase(), ALICE.getPublicKey());
        byte[] data = Convert.uncompress(compressedData);
        return Convert.toString(data, true);
    }

Hope it's helpful :).


You can use the getchaintips RPC, which will list all tips of the known block tree, including branches that were never active.

You may see for example:

{
    "height": 420561,
    "hash": "000000000000000001cb02590846299c91794e9b9f422513cff4b9c1dd5c62a",
    "branchlen": 0,
    "status": "active"
},
{
    "height": 419698,
    "hash": "000000000000000004a3a78750438d0491b6335cbbe9c15099a6e55b6943e51a",
    "branchlen": 1,
    "status": "valid-headers"
},
{
    "height": 418868,
    "hash": "000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805",
    "branchlen": 1,
    "status": "valid-fork"
},

Here you can see that the current best valid chain we know of is at height 420561. There are also two forks:

One branching off at height 419697 and extending to height 419698. It has status "valid-headers", which means we heard about the headers for this block, but by the time they were verified, we already had an equivalent or better block available, so we did not attempt to download the forked block at height 419698.
One branching off at height 418867 and extending to height 418868. It has status "valid-fork", which means we actually heard about this block at a time when it was the best block, and proceeded to download and validate it, which was succesful. Later the branch was overtaken by the branch that is leading up to our current tip.

So this not only allows you to detect reorganizations, but gives information about all historic ones your node observed and/or went through.


Why were private keys made unrecoverable?

By the definition.

Crypto is "unrecoverable money". If you dont like it - just dont use it. Point.


Receiving donation on a bitcoin address and security issues of reusing the same address

For a blog that only receives occasional small amounts you probably shouldn't worry too much about it.  However, if you plan to scale up, here are some things to consider:

One issue with using the same address for all transactions is that people can see the total amount received by that address and know how many bitcoins you have.  If the total is large enough, this might make you a target for attack, especially if you publish personal information along with the bitcoin address.

Another potential issue is that people can see who else is donating to you.  They only see the bitcoin addresses used, but this might be enough to draw some conclusions about who they are.

Best practice is to use new addresses for each donation.  This way there is no link among the transactions except in your wallet, which is only accessible by you.

If you plan to keep bitcoins (instead of just receiving them and cashing them in), you should look into creating an offline wallet.  You could generate a new address for each web page view, and then transfer funds from each of the addresses that received a donation to a different pre-computed offline wallet address.


Lightning Network: How was the maximum allowed HTLCs in flight computed?

The rationale is given in the BOLT #3: for the commitment_signed to be under the maximum message size allowed by BOLT #8 (~65kb), and for the penalty transaction to be able to sweep all HTLCs in one transaction.
Here is a more beginner-friendly explanation of the second part.
The 4000000 Weight Units limitation is the maximum Bitcoin block size limit (link to the BIP).
The 400000 Weight Units limitation is the limit for a transaction to be standard (hence relayed).
The penalty transaction is crucial to the security of Lightning Network channels, so you need a transaction which can be relayed, hence a transaction which size is standard.
But each new HTLC is a two additional outputs to the commitment transactions. Thus two new inputs to the penalty transaction (which spends it). It's an added size (calculated in Weight Units) to the penalty transaction.
So you must restrict the number of in-flight HTLCs to accept (i.e. to add to your commitment transaction concurrently) in order to be sure you can broadcast your penalty transaction if something goes wrong.
Now here is the explanation of the calculation :
max_num_htlcs = (400000 - 324 - 272 - (4 * 53) - 2) / 413 = 966

400000 : the maximum transaction size, cf above
324 : the size of the input corresponding to the commitment transaction output sending funds to you.
272 : the size of the input corresponding to the commitment transaction output sending funds to your peer.
53 : the size of the commitment transaction's non-witness data, this is wy it's timed by 4 to get weight units.
2 : the size of the witness header.
400000 - 324 - 272 - (4 * 53) - 2 : the free room left for adding HTLC inputs
413 : the size to spend an accepted HTLC (used over the size to spend an offered HTLC because it's larger).
(400000 - 324 - 272 - (4 * 53) - 2) / 413 : the maximum number of HTLCs you can accepts so that they can be spent by a penalty transaction which can be relayed by the Bitcoin network.

Because each HTLC creates two outputs, you divide this result by two so :

Thus, 483 bidirectional HTLCs (containing both to_local and to_remote outputs) can be resolved in a single penalty transaction. Note: even if the to_remote output is not swept, the resulting max_num_htlcs is 967; which yields the same unidirectional limit of 483 HTLCs.


What research papers cover Bitcoin's impact on Central Banks, "velocity of money", and reserves?

I don't have a list or a wiki listing all the relevant documents, but the European Central Bank produced this document which covers several types of money schemes including Bitcoin.

Perhaps some lessons learned, and advice from this document can encourage adoption of Bitcoin.


Is it required to broadcast the addresses generated locally to the bitcoin network?

No, you can generate trillions of addresses (private keys) and the rest of the network don't need to know about them until you make transactions to each of them.


What additional benefits can QR codes bring to Bitcoin applications beyond payment requests?

In terms of marketing, here is a very nice QR code that could be used for spreading the word about Bitcoin. It contains a link to bitcoin.org. See this thread on bitcointalk.org for more information. It was created by phelix at bitcoinx.com.


What are protocols in Crypto? What are token protocols?

The bitcoin code creates a network, which follows a consensus protocol.

The bitcoin code can be forked, and parameters tweaked, in order to create similar, but separate and distinct networks (such as dogecoin, litecoin, etc). Each network will maintain it's own blockchain.

In cryptocurrency, the word 'token' is generally used to describe a special type of non-fungible cryptocurrency asset. It is essentially like a special 'earmarked' piece of cryptocurrency, that can be specifically tracked on the network. A token does not have it's own blockchain, it exists on some parent cryptocurrency blockchain. As an example, the ethereum network hosts many tokens, such as TRX, REP, or BAT. The bitcoin network can also support tokens, through the OMNI protocol.

Tokens follow the protocol rules of their parent chain, but could have additional token-specific rules programmed into them as well.


Can we determine which one of the referenced outputs corresponds to a cashback transaction in BTC transaction scripts?

First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g.

round numbers (e.g. three outputs with round amounts and one not)
wallet fingerprinting (e.g. all inputs are multisig, only one output is multisig)
address reuse (some wallets send change back to an address previously used by the wallet)
unnecessary input heuristic
probabilistic graph search
…

The Bitcoin wiki has a whole section in its article on privacy describing approaches for change address detection.


Does mining without a realistic chance of solving a block provide any benefit to the network?

TL;DR:
Mining is heavy duty number crunching, your iMac is useless for that. Running a node helps the network and gives you your own copy of the blockchain. Your iMac should probably be able to do that.

Mining

The purpose of mining is to 1. achieve consensus about the state of the network, 2. confirm transactions, and 3. initially distribute the bitcoins. For mining your machine continuously shuffles the unconfirmed transaction pool and tries whether the current jumble resolves to a valid block. To contribute to the network, you have to have a chance at succeeding at finding a block. With a "mid 2011 iMac" you do not have a chance at succeeding at mining, as explained on In the ASIC-age, is it worth starting mining Bitcoin at home?. Its computational power for the purpose of mining doesn't register, it's a waste of money, time, and unnecessary wear for your hardware. To have any kind of effect, you need an ASIC today.

Running a node

The purpose of running a node is to 1. relay information in the network, 2. check the work of miners for validity, and 3. to have your own copy of the blockchain. Catching up with the network requires some computational effort, but nodes can be run on fairly lean systems. Personally, I run a node on a RaspberryPi 2B, it took roughly eighteen days to synchronize with the blockchain, but is now happily churning along. You can do that with your iMac, but really it's only useful if you either have it running a large part of the day (at least 6h), or are interested in having your own copy of the blockchain. Not sure how well an iMac deals with permanent load though, so maybe it's not the best machine for a 24/7 gig.


Mining software and miners verifications and how accept transactions

There are many approaches to mining.

The leading approach nowadays is to use Getblocktemplate.  The wiki page for that includes a relatively easy to understand example.

There is an implementation in Python called python-blkmaker.


Like any other asset that has a market price, it's all a matter of supply and demand.

The supply side is relatively trivial, the protocol allows for a fixed amount (25 bitcoins at the time of writing) to be produced every tenth minute, this reward is cut in half at regular intervals, and with this algorithm there will never be more than 21 million coins.  However, scarcity by itself is not sufficient, there needs to be a demand as well.  There are many factors behind the demand, I believe none of them are sufficient alone, but some may be more important than others.

A working currency needs to be scarce, divisible, portable, durable, fungible and easy to verify.  Bitcoin scores pretty well on those attributes and was the first digital currency to do so.  However, it's not alone a guarantee to success.  Other cryptocurrencies (aka "alt-coins") may be competitive on all the above.
The belief that Bitcoin will be a viable means of paying for goods and services in the future.  This may cause a sustainable and predictable value.  As an example, assume that 21 million people are buying bread with bitcoins, and in average they'd like to hold enough bitcoins in their wallets to buy 10 breads.  For a brief moment, let's assume this is the only use-case scenario.  With 21 million bitcoins in circulation, that means every user by average has one bitcoin in the wallet.  The value of a bitcoin would then be ... exactly ten breads!
A belief that Bitcoin is "digital gold", a useful means of storing value.  Someone even says ... "payments aren't important, bitcoin is the digital gold, and gold is rarely used for payments" - I believe that's dangerous.  Gold has been established both as a currency and as a "holder for value" for millennias, while Bitcoin hasn't even been around for a decade.  Traditionally almost every currency was both backed by gold and pegged to gold, so all until the 1970s one would indirectly use gold for paying for goods and services.  Gold also has unique characteristics suiting this purpose, gold cannot easily be replaced by other metals while Bitcoins can easily be replaced - i.e. if another altcoin gets more popular than Bitcoin for payments, I predict the BTC-value will drop pretty fast.
Speculation - people hoard bitcoins because they expect the market price to increase further in the future.  As of today, this is probably the biggest driver of demand, and it's by itself enough to spur a price growth, but it may not be sustainable.  Critics compare Bitcoin to a ponzi scam, a pyramide scheme and tulip mania.  Even though none of those comparitions quite hit the mark, if the value is only driven by speculation there is a risk that at some point there may be a crack and the value may fall very fast (like it did when MtGox failed).
Trust in the scarcity.  The risk that the 21M hard limit will be increased through a protocol change is considered small.  However, Bitcoin doesn't have a monopoly on cryptocurrency as such, it's easy to create new altcoins, and there are already hundreds of altcoins which could theoretically replace Bitcoin.
Trust in the security of the transactional system.  The blockchain and proof-of-work delivered by the miners ensures that a transaction remains irreversable and that bitcoins cannot be double-spent.  The cryptographical algorithms used for signing transactions ensures that nobody but the owner of the bitcoin can spend the bitcoin.  It has been argued that the market cap of any cryptocoin have an upper bound in the security of the system; the market cap can never become so big that it would be profitable to buy the processing power needed to successfully double spend or brute-force-engineer private keys corresponding to existing valuable public keys.  Reversely, the same argument can be used to prove that Bitcoin is a secure network (at least when neglecting the risk of phishing, robbery, social-engineering, gaining access to wallets through security holes, exploits or lax password security, missing backup, etc).  The fact that the ledger is secured by an extreme amount of processing work may be one of the points where Bitcoins really excel compared to competitors.
The network effect - this is the (only) thing where Bitcoin excels on the altcoins.  (Almost) everyone that accepts cryptocurrency accepts Bitcoins - but only some few accepts other cryptocurrencies.  Never underestimate the network effect.  Bitcoins may become worthless very fast if some other cryptocurrency takes it's place.
Usefulness for criminal purposes; Bitcoin is perceived to be anonymous, it can be very anonymous if one wants it to be, it crosses borders easily and without regulatory oversight, hence it's the ideal currency for ransom, tax evasion, drug smuggling, crime-as-a-service, etc.  I sure do hope that this is a smaller driver for value than the usefulness for legitimate payments for goods and services.


How do bitcoin nodes agree who first mined ablock?

All nodes agree to add another transaction that mints a certain amount of bitcoins to the miner.

No, every miner already includes the transaction that pays them in their own block template. Whatever miner succeeds pays themselves by means of their block being the winner.

  However, I am confused about what protections there are against a bitcoin node receiving a proof of work for a new block that it did not find itself, and then sending the that block around as though it mined it!

All data in the block is committed to cryptographically via hashes and signatures. The proof of work is based on the hash of the block header, which in turn commits to all transactions via the Merkle root. To claim the reward, one would need to change the output of the Coinbase transaction to send the reward to someone else instead of the miner. This would make the Merkle root that commits to all transactions invalid. So they'd have to change the Merkle root. Well, that would change the block header and make the proof of work invalid. This means that another user can't redirect the block reward, because the instruction to pay out the block reward is protected by the proof of work. If you change a single byte in the block, it's no longer valid.


I am going to buy bitcoins for the first time from a seller on LocalBitcoins. Please guide me.

Meet him at a public place and do the exchange using a phone bitcoin-app and cash. Make sure that his reputation is worth more than a possible robbery/scam.


From what I gather, the deflationary aspects of Bitcoin are tied to the limited supply and  lack of central regulation. I'm still learning about it but here is a collection of articles I put together on the subject: http://wayfinder.co/pathways/530d0adaa30064b367000088/an-economic-primer-on-bitcoin


The testnet Block Explorer doesn't seem to be working. If you go to http://blockexplorer.com/testnet, the most recent block it shows is from August 29, about two weeks ago.


How do I join a NXT mining forging pool? And how do I register for payouts from the pool?

I was confused by this as well, but I figured it out through trial and error. AM means arbitrary message (they should have explained this), which is a regular message you send to the forging pool through your wallet.

First you must join the forging pool (Account Balance -> More Info -> Account Leasing). No additional message is necessary at this point.

After leasing your balance to this pool for some length of time (I waited a few weeks), you will have earned NXT from the pool's forging. When you want to collect your NXT, this is when you send the "AM" (I have found that until you send this message, you will not receive a payment).

In your NXT wallet:

Click on Messages (left navigation bar)
Click Send Message (top right tool bar)
Enter the forging pool address for Recipient (e.g. NXT-K5KL-23DJ-3XLK-22222)
Write anything for the message
Uncheck the Encrypt Message box (I did this, not sure if this is necessary)
Click Send

After your message receives 1440 confirmations (this takes a while), you will receive your share of pool earnings in your wallet from the forging pool. You need to send a new message each time you want to collect your earnings.


There are a lot of people who are hostile to any new crypto-currency, usually because of their vested interest in previous currencies. They tend to audit any new currency's code, looking for things that can embarrass the developers. There's a very good chance that any back door or serious problem would be widely publicized on sites like the Bitcoin forums.

You can certainly audit the changes yourself. Find the closest trusted code base (the one the code you're trying to evaluate is based on), and run a diff. Then look closely at all changes.

Alternatively, you can rely on the wisdom of crowds. Just wait at least a week or so before accepting any updates published by the development team. And search forums likely to be hostile to that project, such as the Bitcoin forums.


Why is two hours the maximum acceptable offset for Bitcoin blocks?

Transactions don't have a timestamp. Blocks have a timestamp. The difference is important, because the block timestamp on some of the blocks changes the difficulty.

  Why is the maximum difference two hours?

It's not particularly important to have very accurate timestamps. Timestamps have two uses:

Difficulty retargeting
Calculating progress of synchronization. If the blockchain started in 2009, and the last block you saw was made in 2012, then you're about halfway done.

  Or, if this is about time zones and summer time, shouldn't they be using UTC time?

They do. Of course, not all systems are set up correctly. For example, imagine a system that doesn't use NTP. The user doesn't know how to set up DST correctly, so they move their computer's clock forward/backward an hour every spring/fall.


What Bitcoin wallet will allow me to participate in an ICO?

Coinbase is mostly used to buy Bitcoins and hold your bitcoins, It is indeed YOUR WALLET, the vault portion of it is actually the best feature they have. You are required to confirm removing the coins often via your phone, and two email address and it gives you 48 hours to cancel on any of the devices.

In my book, this is what a vault means to me, multiple check points before they even move anything out.

Then once they are out they can be moved to any address of your choosing.  Including exchanges like HitBTC which is one I like to sale BTC / BUY ETH for instance, or to another coin or ICO. Most coins I mine can be sold, to purchase BTC and return the funds to Coin Base, and added to the vault for long term.


Is there anyway to check if someone has a bitcoin wallet?

You will have to look through his computers for Bitcoin software or files generally called wallet.dat.

In his papers, you're looking for anything labeled "Paper Wallet", or with QR Codes or long hex-numbers.

Good luck.


Welcome to Bitcoin.SE! Some interesting points that you raise.

Bitcoin is more analogues to gold than more recent traditional banking.

Yes, since power is used in bitcoin mining there are some additional distribution costs certainly. The distribution infrastructure exists anyway and in most cases is not being used to capacity ex-bitcoin, however, the more additional power that a wire carries the more losses there are. If power is in limited supply because generation capacity is being reached then there are certainly additional generation costs, otherwise, the generation cost, in most commercial scale generation projects, is in most cases nothing or close to it.

I heard somewhere recently I think that the total power usage in bitcoin mining is equivalent to the full output of three large nuclear reactors. I wondered what effect that may have on climate myself at the time but rationalised that regardless of Bitcoin, practices in generation need to globally improve. In most countries people either pay for the full cost of their power or, pay the cost of generating it themselves.

It is true that the security of the state is to the advantage of all and is why people are free to engage in things like transacting with Bitcoin. As stated, Bitcoin is more analogues to gold than it is to the banking system. So, Bitcoin currently seems to be about as regulated as transacting in cash, but without the tyranny of distance, and without the value ties of fiat currency and, without centralisation. No central bank can decide to print 21 million more Bitcoin and halve the value of everybody's holdings, much like gold.

With exchanges and Bitcoin Debit Cards, Bitcoin is linked to the local banking system much like any other offshore currency.

In Australia, Bitcoin is legally just like cash. GST and other taxes are payable.


Possibility of hardware wallets being 'unsupported' in the future?

Sure, it's possible that the physical hardware spec could cease to be commonplace (we've seen it before with floppy disks, tapes, PS/2 etc.)

However, Hardware wallets follow BIP39/44/49. In the event that the wallet is lost, unsupported, destroyed, or the company dies, you can always recover your coins by using a software wallet such as Electrum, or even manually. Many open source tools exist to recover coins from seeds.

If at any point the hardware wallets are being deprecated because of actual hardware reasons, it's almost a given that newer wallets will be created, and you will be able to just import your seed from the old one to carry on transacting as normal.


According to BIP32 you're trying to generate a non-hardened child address, see BIP32 - Public parent key → public child key.

Using bitcore-lib, to derive a non-hardened child public key and a P2PKH address:

var bitcore = require('bitcore-lib');
var Address = bitcore.Address;
var PublicKey = bitcore.PublicKey;
var Networks = bitcore.Networks;

var hdPublickey = new bitcore.HDPublicKey('tpubD6NzVbkrYhZ4XLMmry7XriYJ6Xgx1vQqoUZHLUXQPDB32n7pQYaWSMpRttm2sHzYjsQqrsAZYyJCmoEJB51oSdqZxq7epGjP4vHriCYz7Tp');
var orderPublickey = hdPublickey.deriveChild("m/44/145/0/0");
var pubkey = new PublicKey(orderPublickey.publicKey);
var address = Address.fromPublicKey(pubkey, Networks.testnet);
console.log("address", address);

Returns:
address <Address: mkVBk6gZ7rBLYXvpdcKwTEq6SjHvSeLwZ8, type: pubkeyhash, network: testnet>


PBFT algorithm - how do we know how many nodes are faulty?

The n and m parameters are chosen by the implementer when they choose to use the algorithm. For example, I may decide to use this algorithm on 50 nodes and choose to be able to tolerate up to 4 faulty nodes. Thus, my n is 50 and my m is 4.

If I need to design a system to tolerate a variety of different n values, I'll have some piece of code somewhere that, given the actual number of nodes being used (the n value), picks the number of faulty nodes I want the algorithm to be able to tolerate (the m value).

In all cases, n must be known. You have to know how many nodes are in your system or you don't have a system. Then m can be chosen by code, subject to the limitations of the algorithm. Then both n and m are known.

For example, you might have some code that reads a configuration file that specifies the identity of the other nodes in the system as well as the number of faulty nodes that the system is going to tolerate. Then people using that code create that configuration file and load it into all of the nodes. Now you have a usable system.


What's the exact formula where I can calculate my liquidation price on Bitfinex for a leveraged position?

Old question, but I wanted to work this out myself.

The exchange will liquidate your account as soon as it becomes insolvent. There are exchange dependent parameters fees, interest and maybe a threshhold to take into account. I don't know bitfinex values for these.

Ignoring them for now, the general equation works out like:

p(t) = btcusd at time t

p(0) = 1000

leverage = m = 2

initial usd = d0 = 10000

assets(t) = d0*m/p0*p(t)

liabilities(t) = d0 - md0 = d0(1-m)

Liquidated when assets(t) + liabilities(t) = 0, i.e. when d0*m/p0*p(t) + d0*(1-m) = 0

=> p(t) = -(1-m)*p0/m

=> p(t)/p0 = (m-1)/m

For p0=1000, m=2, you liquidate when p(t) drops to 1/2 of 1000 = 500

If anyone has the exchange-dependent data for bitfinex, I'll try to incorporate into the equation.


What is meant by "releasing code tells the hackers what to attack"?

It would appear that Gavin is advising against providing zero-day attack vectors.

Essentially, if someone gives fairly precise instructions (e.g. a code sample) on how to exploit a vulnerability then anyone monitoring that discussion can exploit it. This is the zero-day exploit because no-one has had time to react, create an appropriate patch and disseminate it widely. Until the patch overtakes the exploit then the affected systems are vulnerable.

Consider the famous "Java Double of Death" (see http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ for details, Oracle fixed it here http://www.exploringbinary.com/fpupdater-fixes-the-java-2-2250738585072012e-308-bug/).

Imagine if a malicious coder decided to put that magic number into a request against your web API that and exploited the fact that you haven't patched your JVM? You'd be seeing an awful lot of unexplained JDK downtime and lost business.

There is a fair amount of discussion about this topic over on Security StackExchange which references this Wikipedia page about responsible disclosure.


How can a Ripple contract use random values and reach consensus?

That contaracts wiki page may be out-of-date.
However, the loto example uses rand float which in the data access section of the wiki page is described as:

  this number is deterministically created based on the hash of the collection of transactions or something

That implies to me that it's random only in the sense that the contract itself, or any Ripple user, cannot guess what the value will be at run time, but once running all validators will use the same value.

This is similar to how some Bitcoin gambling sites work, using numbers based off the Bitcoin blockchain hash.


Having change addresses does not change the transaction fee at all.

Whether to use change addresses that are distinct or identical to one of the receive addresses is independent from whether or not to use change.

Change is created whenever the coins (transaction outputs) that are spent by the transaction do not perfectly match the sent amounts. Change results in a separate coin, independent of what address it is sent to. And separate coins need to be spent separately, independent of whether they were sent to distinct or equal addresses.

As a result, change addresses do not affect the size of transactions.


Why would anyone use a payment network based on an imaginary currency?

The currency you are most likely used to right now is fiat money or in other words "imaginary".

  DEFINITION OF 'FIAT MONEY'

  Currency that a government has declared to be legal tender, but is not
  backed by a physical commodity. The value of fiat money is derived
  from the relationship between supply and demand rather than the value
  of the material that the money is made of. Historically, most
  currencies were based on physical commodities such as gold or silver,
  but fiat money is based solely on faith. Fiat is the Latin word for
  "it shall be". http://www.investopedia.com/terms/f/fiatmoney.asp

So I would ask you, why do you use an imaginary currency?


Their bitcoins are no different from any other. Most miners mine in pools where the pool operator initially gets the new bitcoins. Effectively the first thing he does is split them up among the (thousands of) pool participants. They do with them whatever they like.


Which software can I use to setup an e-wallet site?

Most eWallet services would probably be using the standard Bitcoin client running in the server mode. You would then control it through the use of the JSON RPC commands.

But for personal use, you probably want to just use existing eWallet solutions, or commission someone to help you set your wallet up taking into account such concerns as data security, proper wallet backup and so forth (shameless autopromotion - you can contact me;) ).


It's unlikely that this would be a problem. Yes, coins that you send to a mixing service might end up in sketchy transactions. But they are, by definition, going through an intermediary. It's not that your coins are being sent to a drug dealer. Your coins are going to the mixing service. And then the mixing services are sending new completely transactions to that dealer.

So, it would be like the cops showing up at your door complaining that the $20 you spent at the shoe store was later used to buy drugs. I would hope that any police that were smart enough to try to trace the origin of a BTC would also understand the idea that you can't control the other transactions in a mixing service.

Now, there might be some suspicion just because you are using a mixing service. I haven't heard of any cases of this, but it wouldn't surprise me to find out that police would give a drug suspect a hard time about spending BTC through a mixer. But (at least in the US) I can't imagine this being used to harass you unless you were already under suspicion for some other reason. In part, because using a mixer isn't even that obvious: it just looks like any other BTC address. The government would have to be watching your browser or browser history to know you were visiting mixer websites.


can someone give me an example on how collaboration is difficult without the Blockchain?

Short answer: Nobody can give such an example.
Simple reason: Collaboration existed long before blockchain was invented.
Satoshi Nakamoto started chapter 12. Conclusion of his paper with the sentence:

We have proposed a system for electronic transactions without relying on trust.

If you take a deeper look into the technology you realize trust got in fact replaced by distributed computing power. Causing another problem. Namely, how to distribute this computing power in a trustworthy way.
Since voting (as we usually do in democracies) and health care heavily rely on trust in the persons involved I find it difficult to see any reason why and how a blockchain could help in these fields.
Satoshi Nakamoto's paper


This is the correct way to double hash two tx's.
First you need to convert them into little endian, and then convert into raw binary data before hashing.
<?php

function le_raw ($str) {
    return pack("H*", join("", array_reverse(str_split($str, 2))) );
    // return map { pack "H*", join "", reverse /(..)/g } @_;
}
function be_hex ($raw) {
    return join("", array_reverse(str_split( unpack("H*", $raw)[1], 2)));
    // return map { join "", reverse unpack("H*", $_) =~ /(..)/g } @_;
}

$tx1 = le_raw("32650049a0418e4380db0af81788635d8b65424d397170b8499cdc28c4d27006");
$tx2 = le_raw("30861db96905c8dc8b99398ca1cd5bd5b84ac3264a4e1b3e65afa1bcee7540c4");
$v = hash('sha256', hash('sha256', $tx1.$tx2, true), true );

echo be_hex($v), "\n";

output
d47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3


How do I get private key from Bitcoin Wallet for Android

Export it with an export option or derive it from your word seed using a website or other tool.

I'd need more specific information to say more than that.


How can I clone bitcoin 0.16.1 version (not the latest one ) with git command

You cannot directly clone a tree you have to first take the full repository then checkout the commit you want.

For the 0.16.1 version execute these commands in a shell:

git clone https://github.com/bitcoin/bitcoin
git checkout dac5d68

more informations here: https://stackoverflow.com/questions/43411941/i-cannot-clone-git-tree


API documentation for Electrum plugin developers?

Not official by any means, but here's something I cooked up:

https://bitzuma.com/posts/an-introduction-to-plugin-development-for-the-electrum-bitcoin-wallet/

I found these hooks by iterating over Electrum's hook_names object.


What does "P2P peers available. Skipped DNS seeding" means?

Bitcoin Core does not solely rely on the DNS seeders to find nodes to connect to. The peer discovery system first starts with a local database of known nodes that it gathers after having had connections. DNS seeding or fall back seed nodes are only used if the peers database is empty, i.e. the first time you run the software. So this message means that the peers database is not empty, so it will skip the DNS seeders and go straight to connecting to peers from the database.

  What I need to do is to connect two bitcoin daemons that are running in the same machine, with a different genesis block than the main blockchain (both daemons share the same genesis block).

Use the -connect=<ip>:<port> startup option. This option means that the node will connect only to the specified IP address and port and nothing else; it won't do any other peer discovery.


why using `blockIndex` in bitcoin's code `unconfTxs`

That whole vector is to keep track of how many blocks have passed since a transaction entered the mempool and what feerate it is. So it allows the estimator to look up how many transactions have been in the mempool for Y blocks at a feerate of X. This allows it to see what feerate is probably needed in order for a transaction to be confirmed in Y blocks.

If you just had the number of transactions at each feerate, that only tells you the feerate distribution of unconfirmed transactions. This is not helpful for estimating how many blocks will pass before a transaction becomes included in a block.


Getting transactions from mempool to block

You can start to work in a block at any moment, you can even mine an empty block. If any new transaction arrives you rebuild the merkle tree and continue.


Is it possible to transmit a tx over the network that does not go into the blockchain?

This has two problems:

The network still needs to remember those transactions, so this doesn't save storage space.
If someone does a double-spend attack, two nodes could believe two different things about the state of the network, depending on which transaction they heard about first. Over time, their views of the network would diverge more and more.


building a multisig transaction using RPC

if you are on testnet/regtest, it is completely ok, to provide "correct" data (no need for masquerading). There is the famous 2-of-3 multisig from Gavin, which provides a step by step approach using RPC. This should give you the idea behind.

Generally you are correct, you would search for listunspents, take one of the transaction numbers, and see in the transaction, which unspent output you can use (usually it is a 0 or 1 for the first or second). And for sure this transaction should have some amount, that you can spend. Use "decoderawtransaction" to see the details of the tx. When you have created the tx with "createrawtransaction", then it returns a string of data, that can be used as parameter to the "sign" call.


Is there a way to access my BItcoins before Bitcoin qt syncs?

You can either import the keys into an eWallet that allows for that, or try taking your wallet to someone else who has a fully synchronised Bitcoin client. If you replace their wallet with yours (remember to make a backup!), the client should synchronise your wallet with the network and you will see your transactions. You can take the updated wallet.dat file back with you and use it until your Bitcoin synchronises.

Both of those options carry risk - in the first case you entrust the safety of your Bitcoins to a third party, and in the second case - to your friend. The risk could be mitigated (for example, encrypting your wallet will still let it be synchronised, but the private keys will be safer), but should always be kept in mind.


Since wallet.dat is mostly a collection of private keys, you will simply lose all private keys that you have not duplicated or copied. It also by default stores the next 100 Bitcoin addresses it will give you when you generate a new address as a safety measure.
Bottom line
You will lose the copy of the private keys to addresses you've created or added but you won't destroy them. A backup will save you regardless if wallet.dat exists or not. If you restore wallet.dat from a backup, you:

will not lose past transactions, those are stored by the network, not you.
will not lose ownership of any bitcoins you may have acquired under the private keys you backed up, generating a new one and not creating a backup may result in loss. Keep in mind first 100 addresses are stored in wallet.dat.
will not need to know the address of a public key. Those are derived from the private key mathematically.


How are Ripple transaction fees "destroyed?"

The sender's account is debited the transaction fee, but no other account is credited the same amount.


It appears the node is not fully synced the entire blockchain. If your node is not fully synced, then it hasn't parsed the latest blocks to see what a reasonable tx fee would be for the current market. If it's not fully synced, then it might try to estimate based on old transactions, which you don't want, since they could be much lower (and your tx will never confirm), or much higher (and you overpay in fees).


A transaction can spend from multiple unspent outputs and create fewer outputs than were consumed. So it is is possible to aggregate UTXOs.


Convert bech32 Bitcoin address to legacy

As Anonymous says, you simply cannot.

I'll try to highlight the important part of MCCCS's answer:

In Bitcoin Cash, cashaddr ("bitcoincash:...", similar to, but not quite bech32) and legacy addresses ("1..." and "3...", base58) are two different ways of representing the same onchain output in a human-readable way. One can be converted into the other because the resulting transaction will be identical, and the recipient can't tell which address you used.
In Bitcoin, native segwit addresses ("bc1...", bech32) and legacy addresses ("1..." and "3...", base58) are addresses for distinct on-chain outputs. The first are used for BIP141 segwit outputs, while the second are not. The fact that one can be technically converted into the other is irrelevant. If the recipient gave you a native segwit address, it means he expects a transaction that pays to such an output, and he might not recognize a transaction that does anything else. In certain cases, he may be literally unable to access coins sent elsewhere (e.g. because he uses an HSM that can only sign certain transactions).

Short answer: if you're given a native segwit address, and are unable to send to that, there is only one course of action: ask the recipient for legacy address instead.


Who enforces new consensus rules in Bitcoin?

Consensus rules are enforced by economic full nodes i.e. full nodes that are actually using their full nodes to verify and monitor their own transactions. Full stop. In that sense, a theoretical miner not running an economic full node is not enforcing consensus rules, they are attempting to mine blocks with rules enforced by the network of economic full nodes. If that theoretical miner mines a block that doesn't meet those consensus rules the economic full nodes will reject that block.
However, if you are attempting to coordinate the smooth activation of a soft fork one of the ways to minimize the prospect of large re-orgs, confusion and disruption is to get miners to signal readiness. (Signaling readiness is not "voting" for the changes in the soft fork.) Ideally you want all miners to be enforcing soft rules post activation because if a few miners aren't enforcing them a transaction that doesn't meet those soft fork rules could creep into a block and cause a larger than normal re-org. Miners who are enforcing the soft fork rules would reject the block and eventually successfully mine on top of an alternative block but it would need time to work itself out. Of course those miners who have blocks that are eventually rejected lose out on block rewards, transaction fees and transactions that are included in that rejected block will need to be mined in an alternative block.
The focus is only on miner signaling for say the Taproot activation because we want to ensure a smooth activation of a soft fork. We want to know that miners are ready to enforce the additional consensus rules of the soft fork knowing that many economic full nodes may not be enforcing them immediately post activation. However, if there is a "block size war" going on and there are disputes on whether a soft fork should be activated or not (like there arguably were with SegWit in 2017) what ultimately matters is what consensus rules the economic full nodes are enforcing and not what miners signal. In this emergency like scenario you would likely see a lot more economic full nodes enforcing the soft fork rules immediately post activation.
In summary, during peacetime miner coordination and miner signaling does the job just fine and we don't have a problem if a number of economic full nodes aren't enforcing the new soft fork rules immediately post activation. Full nodes aren't creating new blocks and hence can't create a block with a transaction in it that doesn't meet the new consensus rules. (Ideally all economic full nodes would be enforcing them but it is not a problem if they aren't assuming a supermajority of miners are). During wartime however the burden falls onto economic full nodes to determine what consensus rules the network is enforcing. Miner signaling, to the extent that it isn't influencing what consensus rules economic full nodes are enforcing, is irrelevant.


How can I officially prove that a Bitcoin private key is owned by an entity?

A middle man trying to create a business around being a middle man with a technology thats supposed to remove intermediaries?

It seems like you could accomplish what you want with multisig wallet and counterparty.

In the example I have in mind,

The issuer could create an asset that represents qualifications. The issuer could invite their practitioners to a 2-of-2 multisig address and send the asset to that address.

Although we can't confirm if only those two parties have the keys, we can see where the asset came from (but it one scenario it can also be issued by the multisig address and never moved). We can rest assured that it would require both parties, one of which being the individual, to create a proposal to move the qualification asset. And these proposals will be rejected.

Another perk is that the asset can correspond to a centralized system.

Predictable, there's no place for your business in this mix, but that's probably the point, so I would like to thank you and your investors, in advance, for their charity in bringing this idea to the world. Should probably do an ICO


How do I get Raw Transaction Txid, Scriptpubkey Using Bitcoin Core Console

Bitcoin is an open source platform where everyone who runs a full node verifies each and every transaction that has ever happened on the network. It checks that the transaction does not double spend the bitcoins, verifies the signatures (if you set assumevalid=0), and the block structure and proof of work. Thus it takes time for your node to sync up to the current state of the network.

As you have stated in the question, you have just finished downloading the Bitcoin Core software. This means you did not give your node the time yet to finish syncing with the network and verifying every transaction. Depending on the type of machine you are using this should take between couple of days to a week. This is not because of the time needed to download the blocks, but due to the time needed to verify each and every transaction.

If you run your node in pruned mode, you won't be able to query transactions from blocks that are deleted to conform with the prune requirements. Moreover, you will need to set txindex=1 to maintain an index of transaction if you want to query it using txid.


The block chain length in number of blocks will grow indefinitely with one block being created for 10 minutes on average.

The actual size of the whole chain will strongly depend on the following two aspects:

the number of transactions

The number of transactions in a block determine the size of the block. So, the more transactions are made in the network, the more information there has to be stored.

how the block chain will be stored across clients

Since the speed with which the block chain grows has been slightly increasing since the beginning of Bitcoin and the block chain is already significantly big, some of the Bitcoin developers have been considering to implement a solution for this that would make it unnecessary to keep a history since the beginning of time.

Currently already the standard Bitcoin client compresses the block chain for storage. The older blocks become, the more they are compressed. This means that you required less disk space to store the block chain, but also that it takes longer to start building it from scratch. Other clients have to decompress it to share it with you and you will have to compress everything you receive. This results in the fact that new clients often need multiple days to get in sync with the network.


Differences between addresses with the same 20B hash (Hash 160)

Both P2SH and P2PKH addresses rely on HASH160. The difference is in the script.

In a P2SH address (3Hp2zoBKNW5NsmQhHsqKgMwiGA4FoUj9Q4 in your example), the script is a914 B0D5D1FB94B76B39EE82771027BEFD17131042FA 87 (spaces mine). This amounts to OP_HASH160 OP_PUSH(20) B0D5D1FB94B76B39EE82771027BEFD17131042FA OP_EQUAL. In short, the Bitcoin network will take a provided redeemscript and signature data, and compare the hash160 of that redeem script against what is given in the address outputs.

For 1H825FgspbkznbiGAnAjFjan7dmYFjpsFe, the script is 76a914 B0D5D1FB94B76B39EE82771027BEFD17131042FA 88ac (spaces mine). This amounts to OP_DUP OP_HASH160 OP_PUSH(20) B0D5D1FB94B76B39EE82771027BEFD17131042FA OP_EQUALVERIFY OP_CHECKSIG. This essentially tells the network to take the provided public key when spending an input, duplicate it, hash the duplicate, compare it and verify that it equals B0D5D1FB94B76B39EE82771027BEFD17131042FA, then check the signature against the original public key (the one you duplicated).

Wallets and explorers will decide which address format to display based on the opcodes in the script. A P2SH address will always start with a914 and end with 87. A P2PKH will always start with 76a914 and end with 88ac.

Since Hashing by definition is not a one-to-one function, there is some private key out there for which the pubkey hash would be B0D5D1FB94B76B39EE82771027BEFD17131042FA. However, I'm not aware of any known private key/redeem script pairs that correspond to the same HASH160


Is there a difference in buying coins with bitcoin or etherum?

The only difference could be with rounding depending on precision of coins with relation to value to each other. I think most exchanges are governed by law to not steal fractions of pennies but it's always an uncertain point sometimes and so I can not say you aren't in some cases losing fractions of coins.

Also some times on inefficient markets crypto currencies may differ in prices across different currencies. This is an opportunity for arbitrage and typically doesn't exist. This may be caused by sudden changes in the market and usually temporary barriers. Like for example etc goes up rapidly, and LTC had been struggling, there may be a shortage of LTC and so there might be a temporary profit margin through LTC to etc then to btc. But usually the market players will balance things out quickly. It basically the speed of crypto currencies type thing like a ripple in a pond and probably a better topic for forex trading on economics or finance se.

from a math point of view crypto currencies maybe analyzed with linear algebra where your portfolio is a coordinates of vector and basis is the currency to base currency exchange rate. Then redistributing the portfolio amounts to a linear transformation.


Bitcoin trade to money you receive at Neteller to your Neteller creditcard?

LocalBitcoins.com itself actually supports Neteller: https://localbitcoins.com/buy-bitcoins-online/neteller/


Ripple's validation of transactions / Ripple white paper?

Is there a ripple white paper or some safe source to understand how the transactions are validated and made in the ripple network?

Yes. See consensus process and reaching consensus articles.

  VS Bitcoin, XRP is not mined, so how is the agreement reached? (I understand that there is some kind of prioritisation of transactions and the first one agreed gets validated to avoid double-spending, but how does that work if it is not via mining?)

Through consensus between validators (masternodes). They agree on which transaction goes first and sign the new ledger (block). This answer provides some additional details.

  Is there some complete explanation to how Ripple works? Not the oversimplified stuff, but something that actually explains the whole process?

The links above provides a good explanation.


Bitcoin-Qt wallet shows outgoing transaction as "Offline (0 confirmations)"

Offline means that the transaction hasn't been sent to the network, that is, it's not in the memory pool of any other node.

Unconfirmed means that the transaction has been sent to the network and exists in the memory pools of many other nodes.

If the wallet is out-of-sync, that would be the reason it's got 0 confirmations. Even if you did have a confirmation, your node wouldn't know it since the transaction would be in one of the newest blocks.

If the transaction is not on blockchain.info, there's a very good chance that it hasn't been sent. You should probably resend it using the instructions found here.


How to Create a Light Wallet and Light Bitcoin Node, and run it on Mobile?

If you're looking to mine on your phone, it's literally useless. The hashing power on these devices is so low that you'd probably need a very large amount of phones (around the thousands) to reach the hashing power of a single ASIC machine.

Also, storage is an issue because a Bitcoin node needs all of the blockchain data (around 17gb as of today), so you'd need a high-end phone that has a large amount of disk space.


How difficulty variation is technically linked to time take for the block discovery?

The purpose of difficulty variation is to maintain a consistent block time.

Let's say you have a network, and you want a 10 minute block time. You are the only miner. The process of mining can be thought of as rolling a die. For simplicity, let us assume it takes you five minutes to roll a dice once.

Now, we need to set our difficulty such that you find a valid solution roughly every ten minutes. In ten minutes, you will be able to roll the die twice (since it takes 5 minutes to roll once). Thus, we need half the rolls to give a valid result, and set our difficulty to <=3 (since you have a 1/2 chance of getting a number less than or equal to 3 on any roll).

If you do this 2016 times, you will, on average, find a block every 10 minutes.

Now, let's say a friend joins you, and can also roll a die once every 5 minutes. Now, suddenly, we are trying 4 solutions per ten minutes instead of 2. This would result in a block being found every 5 minutes, on average.

After 2016 blocks, Bitcoin nodes will look at the average time taken to find a block over the last 2016 blocks. Once they see that this is 5 minutes instead of 10, they will increase the difficulty by lowering the target. In our case, with two people mining, this would make the difficulty 1.5 instead of 3.

Now, with die, you cannot actually have that much control. There are only six possibilities, which makes your difficulty jump more than you need.

With bitcoin, the blockhash is essentially a 256 bit number, and can store 2^256 values. This allows for fairly precise difficulty adjustments.


Looking for code generate bitcoin address from passphase in C++

You need:

1) libsecp256k1 to calculate the public key from a private key

2) Hash the result with Sha2/256 + RipeMD160

3) Add version byte and 4-byte checksum

4) Encode it using Base58. My minimal code would work.

So, it's not really simple


How do we know which soft-forks were implemented using User-Activated Soft Fork or Miner-Activated Soft Fork?

Most past soft forks have been deployed with miner activated soft forks, and we know this because the deployment mechanisms used only allowed for miner activated soft forks. For a user activated soft fork to happen, the deployment mechanism would have to have some form of activation that is not reliant on miners. Thus far, the activation methods used have all deployed based on miner behavior and not a flag day.
There are two exceptions to this where it could be argued that those soft forks were user activated and not miner activated. The first is BIP 16 which ostensibly activated via a flag day (i.e. all blocks after a certain time must support BIP 16). However the flag day was determined only after a certain threshold of miners signaled support for BIP 16 in their blocks. So while the code was a flag day, the process was still a miner activated soft fork, just done manually rather than through code.
The second exception is segwit. However segwit used BIP 9 as its activation mechanism and that is entirely dependent on miner signaling. So technically, it is strictly a miner activated soft fork. But you could argue that it was user activated because users were running software that would have activated on a flag day, but miners began signaling readiness before that day. So the exact mechanism was through miner signaling, but perhaps it was user activated because users threatened miners by running software that had a user activated mechanism.
For future soft forks, it is likely that a combination of BIP 9 (MASF) and BIP 8 (both MASF and UASF) will be used. You can then determine whether it was miner activated or user activated. For both, miners can signal in their blocks to activate the fork. For BIP 8 only, after a certain time, the fork will activate via a flag day, so if that occurs, then it is a user activated soft fork.
The only soft fork that should be classified as a UASF is BIP 30. This was activated by a flag day and miner signaling was not officially part of the activation.


Can a single wallet generate (and use) both SegWit and non-SegWit addresses?

I am not familiar with the wallets generated by BitPay's Bitcore specifically, but there is no general issue preventing a wallet from generating addresses of various output formats. If BitPay's wallets can only either do one or the other that would be a local implementation quirk.
While it is possible to maintain separate wallets for each user, it is rather costly to do your accounting on-chain.
The more common mode of operations for services that take custody of user funds is to only maintain a single deposit wallet. You would then generate a new address on this "omnibus wallet" for each user deposit. Since the addresses are unique, you can use the address to tell which customer to credit in your internal accounting.
However, on the operational side, you can batch multiple withdrawals into a single transaction and even move part of the funds to a cold wallet to improve your security.


Can I be the transaction processor and take in transaction fees as income without mining a Bitcoin?

No. When miners mine blocks, that is "processing transactions".


Possible attack vector of BIP32 HD wallet

First question: If p was a hardened node, could the attacker still calculate its private key from it's xpub and a child's private key ?

Yes. It doesn't matter how p was generated. What matters is how c is generated.

  Second question: Could the attacker "climb up" the depth (calculate parent's xpriv) from p all the way over to m after calculating p's xpriv from the leaked c key and p's xpub ?

Only if the attacker also has b and m's xpubs. An important part of the derivation is the parent's chaincode. The chaincode is part of the xpub and if the attacker does not have the chaincode, then he cannot derive the parent's private key.

  Would a hardened b or p make a difference here ?

If the attacker had b and m's chaincodes, yes, hardening would make a difference. Hardening entirely prevents this attack. However hardening does not allow someone to have an xpub and be able to generate keys without the private key.

  Third question: If a private key from c's depth was leaked and the attacker knew m's xpub, could the attacker calculate m's private key or does the exploit only permits calculating the direct parent of a leaked child ?

The attack only operates on a child key and its direct parent extended public key.

However, given m's xpub and cs private key, it may still be possible to recover m's private key even though it is not c's direct parent. If b and p are derived using unhardened derivation, then m can be used to derive b and p's xpubs. From there, with all of those xpubs, the attacker can work backwards from c in order to get m.

If b and p are hardened, then it is not possible.

  Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?

Take BIP 44 for example. It define a standard derivation path of m/44'/0'/0'/i/k. The xpub at m/44'/0'/0' is given out. But since it itself is derived with hardened derivation, if any of m, m/44' or m/44'/0''s xpubs are leaked, the user's master key is still safe since hardened derivation is used.

Additionally, Bitcoin Core derives all keys using hardened derivation. This is because it uses BIP 32 for the easier backup function (you can use an older backup and still get all of the same keys) rather than for the auditability.


The order is important.
If you have 24 different words but don't know the order, you have to try up to 24 factorial permutations. That is around 620448401733239439360000 different attempts. This may take a very long time and cause you great anxiety, unhappiness and self-recrimination.

Related questions:

Unsure order of 12 word mnemonic
Bruteforcing a seed with 24 words of a unknown order
Lost my old-Electrum 12-word mnemonic seed order
Bruteforce bitcoin address - I know the words + public address but not the order


Note that all hex numbers and hashes here and in the protocol are little endian. So the ones I show will look backwards from a lot of sites which show them in big endian format.

The Merkle Root

This is a way to combine all the hashes of the transaction together into 1 hash. To do this we first need the hashes of all the transactions. There is only one transaction in the genesis block so let's find its hash. This is based off of this format.

import hashlib

#version 1, uint32_t
version = "01000000"

#1 input transaction, var_int
tx_in_count = "01"

#the default for generation transactions since there is no transaction to use as output
OutPoint_hash = "0000000000000000000000000000000000000000000000000000000000000000"

#also default for generation transactions, uint32_t
OutPoint_index = "ffffffff"

previous_output = OutPoint_hash + OutPoint_index

#77, var_int
script_length = "4d"

#The coinbase. In a regular transaction this would be the scriptSig, but unused in generation transactions.
#Satoshi inserted the headline of The Times to prove that mining did not start before Jan 3, 2009.
#???????EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks
signature_script = "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73"

#final sequence, means it can't be replaced and is immediately locked, uint32_t
sequence = "ffffffff"

tx_in = previous_output + script_length + signature_script + sequence

#1 transaction output, var_int
tx_out_count = "01"

#5000000000 satoshis == 50 bitcoin, uint64_t
value = "00f2052a01000000"

#67 var_int
pk_script_length = "43"

#The scriptPubKey saying where the coins are going.
pk_script = "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac"
#We can decode this.
#41 push the next 65 bytes onto the stack
#04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f the 65 bytes that get pushed onto the stack
#ac OP_CHECKSIG
#This is a pay-to-pubkey output, which is the default for generation transactions.

tx_out = value + pk_script_length + pk_script

#immediately locked, uint32_t
lock_time = "00000000"

transaction = version + tx_in_count + tx_in + tx_out_count + tx_out + lock_time

transaction_bin = transaction.decode("hex")
transaction_hash_bin = hashlib.sha256(hashlib.sha256(transaction_bin).digest()).digest()
transaction_hash = transaction_hash_bin.encode("hex")
print(transaction_hash)
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a

So now that we have the transaction hash for the 1 transaction, we need to find the Merkle root. It turns out that the Merkle root of a single hash is... that single hash. So that is the Merkle root.

Time

29ab5f49, uint32_t. This is 1231006505 in decimal and is a unix timestamp meaning January 3, 2009 at 6:15:05pm UTC.

Bits

ffff001d == 486604799, uint32_t. This is a way to represent the difficulty. It's a sort of floating-point-ish type number. This is difficulty 1 and requires hashes to be below or equal to the target of 0000000000000000000000000000000000000000000000000000FFFF00000000.

Nonce

1dac2b7c == 2083236893, uint32_t

Transaction section

I covered most of this in the merkle root section.

If you want someone else's explanation of each byte of the genesis block, look here.


Official BitPay/Copay support can be reached here:
https://help.bitpay.com/requestHelp

Below are a few tips you can try to make the 12 word recovery phrase work:

Are you sure that the recovery phrase was written in the correct order?
Did you use all lowercase letters and no punctuation?
Did you add a password to your recovery phrase?
Do you have the QR code or text/file backup?
Did you separate each word with a single space (no commas or any other punctuation)?

Please also ensure that your words are all contained in the following list of possible words:
https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt


Should port forwarding for running bitcoin be done also on the ISP's router?

In discussion with @lenlord it seems that his ISP's router does not perform NAT so that his home router has (dynamically) assigned public IP address.

After reading some forum posts and contacting the ISP I found out that some ISPs (and mine is one of them) do indeed hide households behind their NAT (NAT 1 in picture, so called CG-NAT), but that they can remove this NAT for free on demand.

Remove this NAT on the ISP's router is needed to operate bitcoin node with incoming connections.


Where are the user's bitcoins actually stored?

It seems like what's called for here is a basic explanation of two of Bitcoin's big concepts: the wallet and the blockchain:

A "wallet" is a collection of ECDSA keypairs. For those not familiar with cryptography, a keypair consists of a "public key" and a "private key" which can be used to encrypt or sign bits of data. The public key, as the name suggests, is known to everyone and can be used to encrypt messages in such a way that the holder of the private key alone may decrypt them. The private key may also be used to sign messages in such a way that anyone holding the public key may verify that the message truly came from you. Every Bitcoin address consists of such a keypair - the "address" you send people is the public half and the private half resides in your wallet.dat file.
The "blockchain" is a constantly growing database of transaction information which is sent out to all nodes in the Bitcoin network. When you perform a transaction, that transaction is distributed to the network and assuming the transaction is valid, will be included in the next "block." This is where the coins themselves are stored. When you initiate a transaction, all previous transactions to or from that address are scanned and a balance is calculated. If your transaction exceeds this available balance, it will be rejected by the network and will not be included in a block.

It's also important to note that the blockchain technically doesn't store "coins" it stores transaction information. The coins themselves are not discrete things which need storage - when coins are mined the miner's balance is credited via a "generate" transaction which adds to his or her available balance. When coins are sent from A to B, that transaction subtracts from A's balance and adds to B's balance. This is similar to the way that your employer may, via EFT, send "money" to your bank and you can use your debit card to spend that "money" in a store, all without anyone ever seeing a discrete physical dollar bill. Most money in the world today exists merely as transaction histories and balances - Bitcoin is no exception.


Generally if you read BOLT 07 you will see that lightning nodes and channels can either be private or public.

This is independent of the fact if they run on tor or not.

The node announcment message explicitly supports announcing that it runs on tor as written in the BOLT 07

  The following address descriptor types are defined:

  1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
  2: ipv6; data = [16:ipv6_addr][2:port] (length 18)

  3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)

  version 2 onion service addresses; Encodes an 80-bit, truncated SHA-1
  hash of a 1024-bit RSA public key for the onion service (a.k.a. Tor
  hidden service).

  4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)

  version 3 (prop224)
  onion service addresses; Encodes:
  [32:32_byte_ed25519_pubkey] || [2:checksum] || [1:version], where
  checksum = sha3(".onion checksum" | pubkey || version)[:2].

However I think most users running on tor like their privacy and don't announce their node.

Generally nodes can only be announced if they have at least one public channel. This is to prevent spam and DoS attacks on the gossip protocol. As some people only have private channels the nodes will not be announced.

Also most mobile nodes like eclair by default open private channels because it might not be so useful for a user that their mobile phone consumes all the data from their carriers data plan to become a routing node.


Lower confirmation time schemes: any requirement between confirmation time and the probability to find a block during that confirmation time?

The lower confirmation time schemes for mining a block will have a pronounced effect on orphaned blocks, with an inversely proportional relationship prevailing.

Generally this can be explained quite simply; because shorter confirmation times for blocks will mean numerous simultaneous competing chains lengths. Of these competing chains, one will eventually be integrated into the ledger when the block height is greater than the competing chains' heights. However, the chains which are rendered obsolete (ie the shorter chains not integrated into the ledger) will mean orphaned blocks are much more likely as confirmation time decreases.

Take an example where it's 1 minute confirmation times. If there's 4 competing chains each 5 blocks in height/length then all it takes is for one of the chains' blocks to be confirmed in, say, 10 seconds, followed by the next confirmation in 10 seconds (which is not a rare event) which will make the block height 7. Therefore, the other chains of height 5 (or perhaps 6 if a block was solved) will be rendered orphaned, and all Txns therein will be orphaned.

There is a balance that needs to be struck between confirmation time and orphaned blocks, and from my experience with altcoins, the 2 minute mark (as employed by Litecoin) is the functional limit. Ethereum has a much, much shorter confirmation time because it's a totally different kind of altcoin. However for POW coins like LTC/BTC, a ~20s confirmation time is infeasible.


It may be a bit late, but for others coming to this question, Blocktrail have a data and wallet API that supports both Bitcoin mainnet and testnet.

The API provides HD wallets with multi-signature transactions (allowing for full control over your coins should anything ever happen to Blocktrail), and there are currently SDKs for PHP, NodeJS and Python, with more coming soon.

There are also simple examples included in the SDKs to help you get started, a comprehensive API documentation, and a couple of working example projects:
 1. Simple Bitcoin Wallet App
 2. Simple Block Explorer

Disclaimer
I am currently one of the core developers for this API


Have a look at https://blockchain.info/address/1PnwbcQPfWwBPayBvvpcVwK6NjuEmubQTB?sort=0 to check if your payment is on it.


When p2pool is started with --debug, it submits all shares to the node (dogecoind, bitcoind etc.).


Where are my bitcoins - unconfirmed transactions

The transaction d3f86df12c12801ca97244a773287226fd1e833e7151b1ab3a90bff930351e50 has a zero fee, so I doubt it will be confirmed anytime soon. Do you know how to double spend it and specify a higher fee?

The other two transactions also have a very low transaction fee but that would still be OK. The problem is that they are spending from the zero fee transaction. Therefore they cannot become confirmed before the parent with zero fee is confirmed.

You say that you sent those transaction a week ago, but Blockchain shows that it received them yesterday. Maybe they were dropped from the mempool after some days last week and now your wallet did just rebroadcast them. What wallet do you use?


I was able to get my Nanofury working on Linux (rPi raspbian) and bfgminer 3.10.0 with a few permissions changes.  You really have three options:

Run bfgminer as root (undesireable)
Add the user running bfgminer to the "root" group:

usermod -G root -a miner
Change group ownership of the usb device (you will need to determine which one is your Nanofury device):

chgrp dialout /dev/bus/usb/001/006

Option 1 is the easiest, 3 is the most secure.  I went with option 2 as a middle-ground.

I also reverted commit 8383e33 (git revert 8383e33) from the bfgminer git repository, which gets rid of the "reinitializing" warning, and gives me a better hashrate.  I don't know the long-term effect of reverting this commit, though...

To start the miner, I use:

/path/to/bfgminer -S NFY:ALL --set-device NFY:osc6_bits=54

Once you have everything set up, you can write your settings (S, W,  in bfgminer) and you can drop the -S NFY:ALL.  You still need the --set-device, as far as I can tell, though.

Hope this helps!


How could the bitcoin protocol be changed? Has this ever occurred?

Easy.  In the source code add a conditional.  For example, if the protocol were needing to be changed for all verifications after block 200,000 then the pseudo code for that is:

If block <= 200,000:
 # Do it the old way.
Else:
 # Do it the new way.

The problem isn't technical it is political.  If that change causes me pain (e.g., inflate the currency at a higher rate) then I am not going to want to accept any version of the code that does something that I don't want to see happen.

So any change needs to get buy in (concensus), from the developers, miners and ... most importantly, those who will accept bitcoins under the new rules in exchange for something of value.

If an unwanted change is pushed forward without being widely accepted, a blockchain fork will occur, and the losing side (generally the fork with the new rules) essentially gets ignored as if it didn't even exist by the rest of the network.

There have been several changes to the protocol as well as changes to the implementation in the client. Some are planned well in advance (e.g., BIP 16), and some are in response to a problem (e.g., Aug 2010's value overflow).

https://en.bitcoin.it/wiki/Incidents


What parameters are used to calculate the challenge string during bitcoin mining (blockchain creation)?

The data that is hashed, and the hash of which must be below the current target, is the block header. The block header consists of the block version number, the hash of the previous block, the Merkle root of the transactions in the block, the time, the target, and a nonce.

The generation of new bitcoins happens with a transaction, the first transaction of the block, which generates new bitcoins out of thin air. No part of the block can be changed without the hash changing and therefore becoming invalid, and that includes the coinbase transaction's output(s).


No. With current script. There is a locking script, and an unlocking script. Basically the locking script (scriptPubKey) in the old transaction puts down the condition to spend BTC. The scriptSig in the spending tx must provide the data to satisfy these conditions. Problem is, that current script language does not provide an access to data „outsides“ the scripting language. So you would have to define conditions in the locking script „upfront“, while creating the tx. But then the unlock script does not allow for operators, and only accepts „push data“, like pushing the signatures or pubkey. This might change in the future, discussions are running to implement a new scripting subsystem, which is currently checked in a side chain. This will allow to access oracle data (not with „simplicity“ though), which could be a previous tx as well.

Keywords: RSK Elements, Ivy, Simplicity, Bitcoin Smart Contracts,  Scriptless Scripts and possibly some more.

Short answer: currently no.


Payment Channels - Securing the private key that locks client funds

If by "anchor transaction" you mean the transaction that locks some amount of bitcoins to a multisignature address from both yours and your partners private key, then you must keep your private key safe because you will have to sign transactions in both the cases when you will pay, or if you need to refund all the bitcoins back to yourself after some time has passed.

After reading you answer again it seems as if you are looking from the perspective of the receiver. In that case you will still need the private key to be able to sign the (last) transaction that sends you bitcoins from the multisignature address.


Mining profitability sounds too good, where is the catch?

Keep in mind that difficulty also evolves over time: the more hashes the network produces, the higher the difficulty becomes.  As of this writing the difficulty is 148,819,199.  By my computation, each additional 275GH/s rig that joins the network will increase the difficulty by about 40,000; if 4,000 of them are sold, the difficulty will more than double (not counting all the competing mining rigs that may join the network).  And of course, in a few more months, there may be even more powerful rigs available.  So you should expect difficulty to rise, perhaps sharply, and this will decrease your profitability over time.


How would a centralized block chain work?

Sure. You just use a database that keeps track of who has how much money. You can do this any way you want. You don't need anything fancy like POW, POS, or even a blockchain. The only reason you would need or want these things is to permit decentralized operation without a central authority. If you are the central authority, what you say is law just because you said it. So no need for anything fancy.


Satoshi Nakamoto is the elusive and private creator of bitcoin. In October 2008 he published the paper Bitcoin: A Peer-to-Peer Electronic Cash System (pdf warning) which is the basis of the bitcoin client/protocol. He has stated his nationality as Japanese and published a PGP key, has a sourceforge page and aside from that not much is known. It sort of follows that someone interested in creating a distributed pseudonymous online currency would be a very private person.

It is also suspected that Satoshi may be a pseudonym for any of a number of people involved in the original development - a mask used for safety and protection against legal persecution for the creation of such a potentially disruptive product. To that end, Satoshi may still be involved in bitcoin, although as you stated, not publicly. As with everything else about Satoshi, the reason for his lack of current involvement is unknown.


coinbase, where is my btc and will i get bch

There was an announcement sent out by Coinbase on the 27th explaining that they would not be honoring BCH. Coinbase effectively swallowed your attached BCH but should honor your BTC.
Your transaction cannot be cancelled just because the chain hasn't finished verifying it. Additionally, because of the replay security in the BCH blockchain your transfer already happened and the BCH will be created for the account that the BTC was transferred to, namely Coinbase's account, which again does not recognize BCH.


Does BIP44 key derivation path protects private keys derived within same account?

Bip44 doesn't protect anything, if the user has master root key, they could get access to all the other accounts private keys.

Your path is wrong, it should be like that:

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

What you should do is generating child master private key for the following path:

m/44'/0'/1'/

Now the user has access only to account number "1" and should generate addresses using that child master private key and the following path:

m/changeAddress/addressIndex


Does using different addresses affect subsequent transaction size, given the same number of inputs?

Transaction inputs need to reference the Unspent Transaction Output (UTXO) they are spending with the outpoint of that UTXO. The outpoint is the transaction id of the transaction that created the transaction output concatenated with a colon and the output position in that transaction: txid:vout.

Let's say you were sent 1 BTC by P1 to address x1 in transaction uiaex and it was the second output (vout = 1 because we start counting at 0), the corresponding outpoint would be uiaex:1.

The UTXO reference therefore is independent of the address that the funds were sent to previously.

The transaction size is therefore the same whether you received all outputs to the same address or different addresses. There are no savings in transaction size by receiving funds to the same address multiple times.


Is there a chance to return all of the lost money invested when the chart goes back up?

The value of TRX relative to the dollar fluctuates, as do all cryptocurrencies.  Whatever the price of TRX relative to the dollar when you sell TRX is the dollar amount you receive no matter what happens to the price between when you acquired TRX and when you sell it.


Is it possible to spend an output that hasn't yet been confirmed?

Yes you can spend an unconfirmed output.
You can see this in MultiBit if you:

1) Send some bitcoin from one wallet to another.

2) In the wallet that received the bitcoin you can spend it. Because the bitcoin came from one of your previously confirmed transactions, you can trust it even though it is unconfirmed.

Of course, if you spend a transaction that is unconfirmed and it never confirms, then your child transaction will never confirm either.


Transaction for real use / transaction for changin Bitcoin in other currencies?

No, this is not a way that you can accurately calculate this ratio, because trading is often an off-blockchain event. The sequence of events looks something like this:

You send bitcoins to the exchange, using the blockchain. (Or you send fiat money to the exchange.)
You make any number of trades internally to the site. The blockchain is not involved, only ledgers controlled by the site are updated.
You send bitcoins from the exchange to a wallet, using the blockchain. (Or withdraw fiat money.)

Trading volume measurements are measuring step 2 there. That volume is not directly related to the blockchain volume. But, if you have other data too, to help you make sense of it, you could estimate the ratio in question.


Rewriting the entire blockchain: is it possible to spoof block timestamps of a privately mined chain?

Yes, an attacker could spoof the timestamps on the block and create a covert alternative history. However, this doesn't make much of a difference in this attack. The reason is that, if the attacker chooses to manipulate timestamps to increase the difficulty, then they will end up producing fewer, in count, high-difficulty blocks. On the other hand, if they choose to manipulate timestamps to lower the difficulty, then they will end up producing more, in count, low-difficulty blocks. In any case, the cumulative difficulty in the adversarial chain will be the same (both in expectation and, due to a Chernoff bound, with high probability, unless they increase difficulty tremendously).

I'm doubtful about your claim that the network will realize there's a problem. The attacker's chain will remain private until they have surpassed the current honest chain in cumulative difficulty. During covert mining, the honest parties are unaware that an attack is taking place (and the honest chain can continue growing, provided there is some non-majority honest power). The attack will only become visible when the attacker reveals the chain, when the honest parties will instantly switch to it. At that point, the attacker can perform a large double spending attack and walk away prior to the honest parties employing a patch.

One thing the attacker has to keep in mind is that the current blockchain is sometimes checkpointed, so if a client has a checkpoint, then the adversary can only reorg the chain up to that checkpoint. Furthermore, especially near the present, the block timestamps have to match the current time of the verifier computers, as this is checked by some clients, at least approximately. Other than that, this attack could work.


Can't connect to Bitcoin RPC on DigitalOcean server

bitcoin.conf should contain the machine's own IP address as an argument to the rpcbind parameter.

For example, if you are running bitcoind on a machine with IP address 1.1.1.1 and you wish to connect to its RPC server from a different machine, your bitcoin.conf file on machine 1.1.1.1 should contain the line rpcbind=1.1.1.1.


Both of the keys are a part of the Elliptic Curve Digital Signature Algorithm. A private key is just a random number, while the public key is a 2D point coordinate on an Elliptic Curve derived from it. The private key is used to sign messages (in case of Bitcoin - the transactions), and the public key is used to check whether the signature is correct. The public key can either be used raw in a transaction, or turned into a Bitcoin address by means of hashing and other operations.

One can use any library that supports the ECDSA curve used by Bitcoin (secp256k1) to generate the appropriate keypair. There are some online solutions for these tasks, for example my small testing suite website.

However, most commonly one leaves key pair generation to the Bitcoin program. If needed be, the private key can be retrieved from the program by using dumpprivkey Bitcoin API call.


All of the transaction history is communicated between peers over a binary gossip protocol. You can request specific blocks, sequences of blocks, or specific transactions, and clients will normally communicate by broadcasting all of the information they receive to other peers they are connected to - enabling each client to stay mostly up-to-date once they've downloaded the historical ledger. It is required that you connect to multiple peers to request information so that you are sure to get up-to-date information if a potentially malicious peer tries to withold information.

If you are already running a full node (which is a software client which uses the above protocol and stores the valid information it receives), then you already have the transaction history on your machine running the software. For Bitcoin Core, the files are stored in the ./store/blocks/ subdirectory of bitcoin's storage directory. The directory contains many files named blkXXXXX.dat, which are serialized sequences of blocks. Each file contains many Block File structures in serial, up to a limit of 128MB per file. The files are numbered ascendingly, with blk00000.dat being the oldest containing the genesis block as its first Block File. The Block File structure mimics the structure of the information of a block message received over the message protocol, except is prefixed with a magic number and size of the block.

Typically, if you want to write a block explorer, it would be simpler to read the information from the block files stored by Bitcoin Core, unless you need your block explorer to contain live information, in which case you will need to get information over the gossip protocol directly, or through Bitcoin Core's ZMQ interface, because the node software only commits confirmed transactions into block files.


If a double spend is executed, what happens to the original transaction?

A doublespend is a set of transactions which are conflicting with each other. This happens when all transactions are trying to spend some of the same UTXO for inputs. As UTXO can only be spend once, only one of the transactions of the set can be confirmed. When one gets confirmed, all the others become invalid, the invalid transaction will then be forgotten by the network at that point.

Just be sure that some of the inputs match, otherwise you're sending the payment a second time instead of creating a conflicting transaction.


Does `importprivkey` need a rescan even in a txindex=1 node?

Yes. txindex=1 is not related to the wallet and the wallet does not know about the txindex nor does it care. What the wallet really cares about is transaction output information and which transactions are related to addresses stored in the wallet. The txindex does not store any of that information, all it stores is the location of each transaction identified by transaction id. The actual contents of that transaction are not kept except in the raw transaction itself.


Wouldn't the blockchain size become a bottleneck if all payments happened on Bitcoin?

That would indeed create a lot of data. However, there are solutions for this.

First of all, as a normal consumer you don't store the blockchain anyways. Only some nodes like Bitcoin services and generally those who choose to store the blockchain.

Secondly, even as a miner, keeping the UTXO pool available fast is important. They don't need the entire blockchain which shows you all previous payments available at high speeds. They only need to know what unspent money there is and how it's possible to spend it. That's much less. Storing the blockchain itself isn't much of a problem because storage space is super cheep, compared to mining equipment and their energy costs.

And third, what you probably want to know, high activity on the main chain can and very likely will be avoided via lightning networks and payment processors. Both have their own advantages and disadvantages, of course. You can read about lightning networks in the linked Bitcoin wiki article. I wrote about payment processors 2 hours ago in my answer to this question.


How can I find out where I sent my coins just from an address?

I am pretty sure that there is no way to identify who or where you sent the bitcoins. Bitcoin is designed so that anybody can view your transaction but nobody should be able to take away private information (like the name of the company) from the publicly accessible address.


If you're looking for the 'quick around' investment, you probably should have money/coins sitting in both accounts. Bitcoins and other cryptocurrencies tranfer nice and quick, but fiat cash is alway SLOW... too slow. Expect the worse case scenario when moving fiat cash. There is no incentive to move your fiat cash quickly. (and thats why we love cryptos :D )


Make sure you are factoring in taxes and fees charges by the exchanges. Although, if you were to sell on localcoins it would be less expensive to transact in multiple currencies and you save on exchange/broker fees.
But it is basically that easy afaik. Just like any other currency trading (including forex) some currencies are worth more than others at a particular point in time.
You should also ask yourself if your method of transaction is fast enough to do this kind of trade and make the profit you expected

That being said, in the last few weeks people Have been buying XBT with USD and selling XBT for CNY at a premium and then converting that CNY to USD and making a nice chunk of change.
The reason for this is that Chinese citizens have limited access to USD and because most XBT exchanges transact in USD the Chinese can not buy XBT easily. Therefor the chinese pay a premium for their XBT.

What about trying your hand at alt-coin trading on a minimal investment... Say $10 USD. You can learn a lot about these systems of exchange, including where to get XBT cheaper.

XBT = BitCoin


Differentiating Output Script (scriptPubKey) Types

thx for linking one of my older pics from 2016 :-) meanwhile things had changed, especially the multisig was not clear enough. I attach an updated version here. I didn't have the time to put newest SegWit related things into the pic though...
Still happy to see other opinions ...


Probability that a block will be confirmed in x minutes

The time T until a block is mined follows an exponential distribution.  Assuming the difficulty has properly calibrated to the network hash rate, the rate parameter for T will be λ = 1/10 per minute.  So the probability that the block is mined within t minutes is
P(T <= t) = 1 - exp(-t/10).