What is the difference between BTC and Bitcoin Core?

Bitcoin Core is a specific implementation of the Bitcoin protocol, specifically the one in the Bitcoin GitHub Repository. It is the evolved version of the original client Satoshi wrote, in C++. It is also the reference implementation of Bitcoin.

But Bitcoin Core is not the only Bitcoin node software, there are others written in other programming languages and with other extra features, for example there is bcoin, btcd written in Go, Bitcoin Knots, Bitcore, etc.

When being compared to S2X, Bitcoin Core is sometimes used to refer to the Bitcoin protocol defined by the Bitcoin Core reference implementation - i.e. Bitcoin itself, to avoid confusion. Bitcoin Core is also sometimes used to refer to the developers of Bitcoin Core, but it must be noted that Bitcoin Core is not an organisation, it is a piece of software.


Permissioned or Permissionless blockchain? Which one is PoS more adapted for?

Frankly, I don't think your definitions are useful. But by your definitions, PoS makes a network permissioned by definition. In a proof-of-stake network, you can only participate in the validation of transactions if you possess the token, which you can only get from someone else who has the token and chooses to give it you. By your definitions, that makes the system permissioned.

Again, I don't think your definitions are useful.

To propose more helpful definitions:

A system is permissionless or public if it permits open participation in both the submission of transactions and the choice of transactions to make forward progress on. There must be no special permissions required to submit and execute transactions beyond the possession of some way to pay transaction fees, and this must (in actual practice) be widely and easily available to anyone who makes a reasonable effort to acquire it. The method in which the ledger makes forward progress must justify a reasonable expectation that hard censorship will not occur -- that is, anyone who submits validly signed transactions to the network should be able to reasonably expect them to execute without having to worry that some particular clique or group can decide to disallow their transactions specifically.

A system is permissioned or private if it does not permit open participation in either the submission of transactions or the choice of transactions to make forward progress on. That is, submitting a transaction requires some permission beyond mere possession of a widely-available, anti-spam asset or participants cannot reasonably expect the system to resist censorship, that is, not all participants have reasonable assurance that their transactions won't be discriminated against in a way that significantly affects their ability to use the system and get its benefits.


How do we know that a user owns multiple private keys?

There are multiple articles available in internet which contain that paragraph. For example: http://cs229.stanford.edu/proj2014..., https://arxiv.org/pdf/1611.03942.pdf, etc
Each one seems to attribute the origin of the data to different sources, but the numbers act as a fingerprint (6,336,769 nodes and 28,143,065 edges), so it can be traced back to a work by Ivan Brugere which seems to have been available in the past, but not now, at compbio.cs.uic.edu, and from which some docs remain at github.
From them he refers to the work "An Analysis of Anonymity in the
Bitcoin System" by Fergal Reid and Martin Harrigan:

Suppose U is, at first, incomplete in the sense that each vertex represents a single public-key rather than a user and that each directed edge between a source and a target represents an input-output pair of a single transaction, where the input's public-key corresponds to the source and the output's public-key corresponds to the target. In order to perfect this network, we need to contract each subset of vertices whose corresponding public-keys belong to a single user.
... as noted by Nakamoto:
"Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner."

And closing the argument, in an extensive work covering the same dataset:
Analyzing the Bitcoin Network: The First Four Years - Matthias Lischke and Benjamin Fabian, Institute of Information Systems, Humboldt-Universität zu Berlin, Spandauer Str. 1, 10178 Berlin, Germany (CC BY 4.0):

The user information is organized by the second group of files [...], where a “user” is a grouping of public keys that were used as inputs into a single transaction (user owns the private key to each address) as proposed by Reid and Harrigan. Each line [...] is a grouping of public keys as illustrated in Figure 3:


What changed about coinbase.com to make it a "regulated exchange"?

As the Reddit post linked in your answer points out, the Coinbase that we already knew uses ACH transactions to move money in and out of your account, which makes it not very good for day trading.

Coindesk coverage of the new exchange states that Coinbase previously acted largely as a brokerage for Bitcoin users. A brokerage firm trades securities on behalf of investors. In contrast, an exchange is a market where brokers and dealers meet, with infrastructure to facilitate buying and selling. The Coindesk article goes onto state that Bitcoin will have a full order book, which is a list of interested buyers and sellers for each financial instrument. A matching engine uses the list to determine what trades can be made.

In addition, Coinbase needed money transmitter licenses to operate as an exchange.  They already obtained money transmitter licenses in order to legally operate USD wallets (which is why their USD wallets are not available in all US states), but Bitcoin couldn't hope to operate as a legal exchange in the United States without money transmitter licenses.

Regulations in the United States have required that certain types of Bitcoin businesses have money transmitter licenses, as business attorney Marco Santori explains:

  The Financial Crimes Enforcement Network (“FinCEN”) is the bureau of
  the US Department of the Treasury that enforces federal regulation of
  money services businesses in the United States.

  On March 18, 2013, FinCEN published guidance announcing that it would
  make no distinction between transmitters of government (or “fiat”)
  currency and transmitters of bitcoin, which it now famously referred
  to as a “decentralized convertible virtual currency”, rather than by
  name itself.

  Thus, businesses that transmitted, sold or exchanged bitcoin were now
  Money Services Businesses, specifically “money transmitters”, required
  to register with FinCEN and satisfy ongoing record-keeping and
  reporting requirements. From the perspective of the federal
  government, an entire industry of visionary startups that had not
  already registered, and had no intention of registering, became
  potential criminal enterprises overnight.

He goes on to state that spending Bitcoins on goods / services does not make one a money transmitter, but that transmitting money (fiat money or cryptocurrency) does. In addition, exchanging fiat currency for cryptocurrency, cryptocurrency for fiat currency, or even between different cryptocurrencies makes one a money transmitter in the eyes of the US federal government.


Possible to get Blockchain bitcoins over to Stripe or Paypal?

You can use a crypto currency exchange to move funds from one currency to another.

For example you can sell Bitcoins for USD or other fiat currencies and payout the amount to a credit card or a bank account.


Why did Dogecoin fork into 3 chains and not just 2?

The articles you link attribute the forks due to raising the total coins limit. Which changed from 500 million to 10 billion. Now this by itself won't cause a block chain to fork, until there is a transaction larger than how many coins there should exist according to old and outdated clients. In Dogecoin's case someone created a 500+ million transaction that would create an invalid block from an old node's perspective.

To create multiple forks, you'd simply stem from newer blocks in the "outdated client" chain. Old clients would reject it and opt for blocks created by outdated miners and newer clients would be hit by a self inflicted 51% attack of sorts. Where newer nodes have multiple chains to sort and make a decision on. As an example here are the chains a newer updated node would have to choose from.

Original client chain
Original client chain with leading block containing one 500+ million transaction
Original chain with second-last block containing 500+ million transaction

It goes with the longest chain initially, but what happens if another chains mines a few blocks faster and becomes the leading chain? It switches over, and you have this complex multi chain scenario.

Why was the total coins possible limit increased?

The creator simply didn't expect this, all though it is really expectable. Dogecoin was set to mine itself out entirely within 1.5 years from release. Compare this to Bitcoin's ~2 centuries from now. Whoever configured these initial values expected Dogecoin to become irrelevant within this time frame or simply wanted cosmetically large block rewards to entice people.


Is there really this big a difference between AMD and NVIDIA?

Is there really this big a difference?

Yes.

  As on many websites it says AMD is so much better for mining while because NVIDIA has Cuda everyone says its best for editing why doesn't cuda drive up Mhash/s?

CUDA's a software framework for making GPU-based software eaiser to write. More stuff supports NVIDIA cards. Bitcoin GPU miners support both, so CUDA doesn't matter.


Mining with BFL at 440 GHS over 24 Hours and no bitcoin?

Consider consolidating to one pool.  Pools have a payout time "window" for example, shares per 24 hours. So, the more shares per 24 hour windows mean a bigger slice of the BTC block.

Three pools, no usernames?  How are your miners ID'd in the pools' systems?  Pools usually require an account/username to ID your miners' work for payouts, unless you're using P2Pool, then it's just your payout addy.

My first idea is, unless you're using one of the BIG FIVE pools, you only get a payout once a block is found in that pool.  BTCGuild, DiscusFish, Eligius, GHashIO, Slush...those see 5-20 blocks a day.  Other pools see much fewer, so don't expect any constant payout unless you're in one of the BIG FIVE.
My second idea is difficulty.  2.2+ billion difficulty is rough on a mining chap, and luck plays a big part when mining (many don't tell you that).


I would envision that when the waiter brings the bill, there would also be a QR code printed on it.  This would be a one-time address owned by the restaurant, and given only to this customer for their particular bill.  If payment is made to this address, then the restaurant knows that the customer paid (or at least someone did).  An amount would probably not be included in the barcode, which would make it easier for the customer to send extra as a tip to the waitstaff.  This is similar to when a customer leaves a stack of banknotes on the table as payment, indicating that the waiter keeps the change as a tip.  The restaurant would be responsible for distributing tips to the waitstaff, just as they are today when you pay with a card.

Alternatively, two barcodes could be printed on the bill.  One would encode the address and amount of the bill to be paid to the restaurant, and another for the address that goes to the waitstaff.  I feel this would be less likely, since it is less convenient to the customer, and makes it more difficult to divide tips in cases where the tips are shared by the whole waitstaff.

By using a barcode printed on the bill, the restaurant's ticketing system will have incorporated the Bitcoin wallet, so the waitstaff does not need to worry about it.  The system would monitor addresses given to customers, and show an idicator when a customer has paid.  The waiter will have very little interaction with Bitcoin, if at all.


resolved now, it was the web interface causing a mass of errors that crashed the system.


How can I tell whether transactions were (not) made via BitPay / Coinbase?

Only way is if Coinbase/Bitpay publicly released their addresses, which they won't.


Ethereum - how is the output of a contract computation verified?

Other nodes do the same computation, in a deterministic fashion, and they compare their result to the result the miner got. That's why there's no function that returns random results - different nodes would come up with different numbers, and the chain would fork. All other miners verify your block, and the penalty for building an incorrect block is losing the block you mined.

But there's a related question: can you gain an advantage by improving the speed of the VM, or skipping computations somehow?

I think you could. For example, you could offload the computations to a GPU. Even though Dagger is GPU-resistant, the VMs require a small amount of memory and could probably be run on a GPU.

The advantage would be pretty slight, though.


Why is there separate private key for every adress? What should i record for my paper wallet?

Why is there separate private key for every adress in litecoin?

Because that is how public key cryptography works. Each address is the hash of a public key, and each public key only has one private key. Thus each address has its own private key.

  What should i record for my paper wallet?

The private keys of your addresses. You should really only be using paper wallets for long term storage. They are not very good for doing transactions.


Would a transaction with a $0.01 fee get confirmed? If so, how long would it take?

This changes with time, a lot. About 3/4 of a year ago, I made several test transactions spaced out over several days with very low fees, today worth between 1 and 5 ¢. (Unless stated differently: ¢ = 0.01 $; $ = USD) They all got confirmed within a few blocks time.

I just checked my transaction history and the one with the lowest fee I was able to find had a fee of 0.000023 BTC and a size of 226 B.

Right now, 1 BTC is worth 1'037.71 $. This means that my lowest fee of 0.000023 BTC is worth 2.39 ¢. However, it was worth less than 1 ¢ at the time.

Concrete info about the current state of affairs would get outdated very quickly. If you visit a page like http://bitcoinexchangerate.org/fees, it tells you the recommended fees for getting a transaction confirmed within different periods of time.

Right now, a transaction having a fee equivalent to only 1 ¢ will not get confirmed within any reasonable period of time because there are many unconfirmed transactions having a better fee per size than any transaction with only a fee equivalent to 1 ¢.

To give you a rough impression: The 48'000 transaction blockchain.info currently has in its mempool (go check https://blockchain.info/unconfirmed-transactions for the current numbers when you read this) have a cumulative fee of 54 BTC.

The last few blocks were all full (very common, right now) and collected an average of 1.66 BTC in fees. Go click the block heights in the top table of https://blockchain.info and find the average of the fees the last few blocks took. The table corresponding to each block has an entry called "Transaction Fees".

This means that 1 B in a block is worth 1.66 μBTC (if we neglect the block header). Even for a very small transaction of 226 B, that means it takes 226 B * 1.66 μBTC/B = 0.37516 mBTC to buy enough space for it in the blockchain. At Bitcoin's current value, thats equivalent to 0.3893 $.

Of course, the fact that some transactions which get in a block have a higher fee per size than others mean that you don't have to beat the average. But you have to get pretty close to it. And it's not looking like the BTC equivalence of 0.01 ¢ will (for any transactions) be pretty close to that average any time soon.

There will have to be a solution to so few transactions going through, compared to how many there are, though. There are several proposals to this and if implemented, those solutions would bring the cost required to get a transaction confirmed down.


All Bitcoin Public Keys with non-zero balance

You can't get a database of all such public keys, but you can get some of them.

An address, as you know, is a hash of a public key.  When somebody sends coins to an address, you can think of the associated public key as having a positive balance, but nobody else necessarily knows what the public key actually is.  (You can't compute the public key directly from the address, because hash functions are effectively one way.)

However, in order to spend the coins from that address, the spending transaction has to reveal the public key (so that the spending transaction's signature can be verified).  So what you need to look for are addresses with a positive balance that have also had some coins spent.  I am not aware of any simple way to do this short of making an index of all transactions.  It is possible you could rig up a way to produce such a list by querying a fully-synced bitcoind using -txindex (so that all transactions are indexed), but it seems likely to be inefficient.

But as a randomly chosen example, consider the address 1Q6NNpHM1pyh6kEqzinBhEgsRc3nmpTGLm.  It is associated with some public key which has a balance of BTC 259.7299, but since (as of this writing) no coins have been spent from that address, nobody except the owner of the address knows what the public key is.  So your database will necessarily be incomplete; probably very incomplete.

In particular, most people use a new address for each of their transactions (including change addresses), in which case the transaction that reveals the public key for an address also spends all its coins (so that the balance is now zero), and that public key will likely never be used again.  This strategy is used partly because certain theoretical cryptographic attacks are easier if the public key is known, and this strategy mitigates the risk from such attacks; it also increases privacy by making it harder to look at patterns of transactions to try to deduce who the address belongs to.

Another case in which you can learn the public key is so-called P2PK transactions, where the output script includes the actual destination public key, instead of merely its associated address.  These were common in the past, but these days all standard clients use the P2PKH transaction type, in which only the address is used.


Do local nodes work across crypto types?

No, while there are some wallets that support multiple coins, the full nodes of each cryptocurrency network generally have their own distinct node software. In particular Monero and Bitcoin will require separate software.


Using vanitygen To generate addresses for different cryptocurrencies

I found some here.

LTC: 48
FTC: 14
NVC: 8
ANC: 23
PTC: 47
CNC: 28
DGC:30
NMC: 52
PPC:55
YAC: 77
BQC: 85
IXC: 138
DOGE: 30

Proper syntax for VanityGen is: (from this question)

Usage: vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...]
Generates a bitcoin receiving address matching <pattern>, and outputs the
address and associated private key.  The private key may be stored in a safe
location or imported into a bitcoin client to spend any balance received on
the address.
By default, <pattern> is interpreted as an exact prefix.

Options:
-v            Verbose output
-q            Quiet output
-r            Use regular expression match instead of prefix
              (Feasibility of expression is not checked)
-i            Case-insensitive prefix search
-k            Keep pattern and continue search after finding a match
-N            Generate namecoin address
-T            Generate bitcoin testnet address
-X <version>  Generate address with the given version
-t <threads>  Set number of worker threads (Default: number of CPUs)
-f <file>     File containing list of patterns, one per line
              (Use "-" as the file name for stdin)
-o <file>     Write pattern matches to <file>
-s <file>     Seed random number generator from <file>


Yes, independently operated nodes help decentralization more than the same number of nodes operated by a single entity.  That's basically the definition of "decentralization" in this context.  That is not to say that a single organization running multiple full nodes does not add to overall network health, since those nodes still participate in relaying transactions and providing historical blocks.

As for your other questions:

It is very difficult, if not impossible, to identify which nodes are run by which organization.  Nodes are often run using proxies/TOR to obscure their true IP addresses, which is often the only way to determine ownership.  If we don't know which nodes are run by whom, we cannot correlate which nodes are run by the same entities.
Without a solid answer to question 1, I don't think there is a good answer to question 2 either.

You could assume that organizations running multiple nodes will broadcast or relay transactions from all their nodes simultaneously.  If so, then you could figure out which nodes are a part of which group by having many nodes on the network, yourself. Then you could correlate which nodes first relayed which transactions.  However, the initial assumption is bad, and adequate tracking would require you to have a large number of nodes on the network.  I don't think your results could be trusted enough to be worth the effort.

In a permissionless system such as Bitcoin, it is intentionally hard for anyone to know that much about the other participants.


They are not. They might be provided to try to provide a better explanation, but I don't even think that this purpose is achieved. There are several sentences throughout the article that make no sense at all, like:

  A bitcoin, at its core, is a very simple data ledger file called a 'blockchain'. A blockchain's file size is quite small, similar to the size of a long text message on your smartphone.

I would recommend you to look at the question you mentioned , that actually have two really good answers, and ignore the first article.


Which data should be used in order to detect addresses to be used for fraud?

Fraud and money laundering are two different things.  Fraud, or accepting or spending money under false pretenses, would be very difficult to detect on the blockchain because it requires outside knowledge.  The way banks detect fraud is by using the context of what was purchased, and where.  The blockchain doesn't contain that information, so supplemental data would be required for detection.  Most fraud would appear identical to legitimate transactions on the blockchain.

Money laundering, however, can be detected...just not very well.  Mixing services are what you'd have to look for, since they would be the most obvious way to obfuscate the origin of some bitcoin. These could be detected by looking for chains of transactions with large numbers of inputs and outputs that are then spent shortly thereafter by other transactions with large numbers of inputs and outputs.  Mixing services generally tumble and mix coins together like this for several hours before they finally come to rest in a UTXO.

However, there are several problems to this approach.  First, mixing services are not exclusively used by criminals...not by a longshot.  Many people use them simply so that whomever paid them bitcoin can't later look up how they spent it.  Second, there are many other types of services that will have a very similar pattern on the blockchain.  Payment processors, exchanges, and web wallets all bundle inputs and outputs together in order to minimize transaction fees.  They all create similar-looking chains of transactions.  Trying to detect money laundering in this fashion will result in a rather hefty paradox of the false positives, meaning it will be difficult for you to derive accurate conclusions from your findings.


Does an incorrect preimage cause intermediary nodes to discard a Lightning payment?

You will find the answer to your question in BOLT 02 in the section about the update_fulfill_htlc message

from there I quote:

  If the payment_preimage value in update_fulfill_htlc doesn't SHA256 hash to the corresponding HTLC payment_hash [the receiving node] MUST fail the channel.

This goes for every local HTLC so if Charlie sends the wrong payment_preimage Bob will fail the channel with Chralie. If Bob alters the preimage Alice will fail the channel.

Whoever fails the channel should fail the onion as the path does not exist anymore. Reading BOLT 04 I guess it returns

  type: PERM|8 (permanent_channel_failure)

But I did not double check in the implementations


Is a gold standard commodity-backed bitcoin possible?

A true "gold standard" means that a unit of currency (e.g., "dollar") has a certain amount of commodity backing it (gold, in the "gold standard" instance), and that the currency can be exchanged for that commodity at the designated exchange rate.

The amount of gold per dollar is fixed under a gold standard, so a dollar on one day gets the exact same amount of gold as does a dollar the next day.

The U.S. went off the gold standard (currency "backed" by gold) in 1933.  After WWII it allowed central banks to exchange dollars for gold at a set rate ($35 per ounce of gold) however that ended in 1971.

But iust like gold doesn't have any "backing", there is no backing for Bitcoin.

There could be a paper currency (or electronic transaction) that has bitcoins as the backing.  Essentially that is what every hosted (shared) EWallet provider offers -- an account through their service which presumably every BTC deposited is still available for withdrawal (e.g., they haven't spent it, invested it, loaned it out, or lost it).

Redeemable codes would be an example of an electronic currency that is has backing where each BTC issued is 100% backed (with a BTC held).  There's no way to audit that to guarantee that they have full backing though.

So just like gold doesn't have any "backing", it makes no sense to have backing for Bitcoin.  Bitcoins themselves have value, due to their scarcity and other reasons.

If you are looking for a guaranteed value in case the bitcoin exchange rate drops then there are PUT options that you can buy.  That's an investment product though and not a part of the currency itself.

[Update: If you want a gold-backed electronic currency, Peter Schiff's Euro Pacific Bank Ltd (not available to those in the U.S.) essentially offers that.]


The images in the original thread are broken, but the text states that poster on bitcointalk placed the work in the public domain, i.e. the most permissive CC license. Prior to this the logo with "BC" was openly licensed by its inclusion in the Bitcoin source code.


How to Create Seed Node for Cryptonote Fork

Make the build again after adding below changes in src/CryptoNoteConfig.h

Add IP addresses of your seed nodes.

Example:

const std::initializer_list<const char*> SEED_NODES = {
  "192.168.0.11:17236",
  "192.168.0.12:17236",
};

OR

create one file coin.conf in cryptonote/build/release/ and add below lines

seed-node=192.168.0.11:8080
seed-node=192.168.0.12:8080

and start the node with below command

$ ./yourcoind --config-file coin.conf

source :

https://cryptonotestarter.org/inner.html

http://forknote.net/guides/setup-private-blockchain/


Has anyone tried transfering 0.00000001 BTC (the currently minimum amount) successfully?

Yes, I have successfully transferred 0.00000001 BTC (commonly referred to as a Satoshi) before.

What is possible within the scope of a MtGox withdrawal is another question entirely. MtGox uses a custom client and has a fee structure and other assorted math to contend with that may not allow for such a transfer at present. If your withdrawal has not appeared in Block Explorer you should contact MtGox support as it may reflect more on their modified system than the default behavior of Bitcoin.


Issues Still With Import Backup dat.file

From Microsoft's documentation on how to open a command prompt window:

  Open the Command Prompt window by clicking the Start button, clicking All Programs, clicking Accessories, and
  then clicking Command Prompt.

Also:

  Here's another way to open a Command Prompt window: Click the Start
  button. In the Search box, type Command
  Prompt, and then, in the list of results, double-click Command Prompt.

Once you do that use the cd command to "change directory" to wherever Bitcoin is installed to (probably C:\Program Files (x86)\Bitcoin or C:\Program Files\Bitcoin).  From there you should be able to type bitcoin-qt.exe -rescan and be on your way!


Question - To spend the funds how do I sign them I mean do I sign them using the TPriv key or I need to derive a private key from the TPriv key ?

To spend the UTXO of a child address (derived from either your xpub or xpriv), you will need to use the xpriv key to derive the child private key that is related to that address. The child private key will be used to sign the transaction, the parent private key cannot sign for child UTXOs (with or without the chaincode).


According to https://en.bitcoin.it/wiki/Mining_hardware_comparison the best GPU in regards to power consumption is the 5970, the tricky part is finding one of those for sale.


How to get block headers from block hash using P2P API?

The block header is part of the block, so you can request the entire thing and just consider the first 80 bytes. Software generally shouldn’t need to do this though.


How can I generate an address with some string on it, which will check as correct?

Note that while your question is interesting as a learning exercise, writing messages into the blockchain in this way is not recommended as you are increasing the UTXO set. You are encouraged to use 'OP_RETURN' instead. There is a thread to which your question is related, but it does not seem to focus on the aim of creating an address with a specific message in it.

A bitcoin address (of type 'P2PKH', i.e. 'pay to public key hash') is simply a 25 bytes number, where the leading byte is 0x00 and the last four bytes (low order bytes) constitute some checksum which guarantees the address has no 'typing' error. Specifically, the last four bytes of the address are the first four bytes of the hash (specifically the double Sha256 hash) of the first 21 bytes (highest order) of the address. So in big-endian representation, a bitcoin address looks as follows:

address (25 bytes) = [0x00][20 bytes][checksum (4 bytes)]

As it turns out, since you are not concerned about recovering any fund sent to your address, you have complete freedom on how to choose the 20 bytes (normally those 20 bytes would be some hash of a valid public key). The only constraints you have are the leading byte 0x00 and the last 4 bytes which will depend on how you chose the 20 bytes.

Now suppose you wish to send the message "HelloWorldHowAreYouIamOk".

One naive approach consists in focusing on the number 1HeLLoWorLdHowAreYouiAmok111 (expressed in base 58) which is of length 21 bytes with a leading 0x00 byte, calculate the hash (double Sha256) of these 21 bytes, keep the first 4 bytes of the hash and append these 4 bytes to the 21 bytes. However, the operation of appending 4 bytes to the right means you are effectively multiplying your 21 bytes number by 256^4 and then add the 4 bytes number. This will completely mess up the Base58 digits of your initial number.

So what you need to do instead is focus on the number 1HeLLoWorLdHowAreYouiAmok111111111 (expressed in Base58, add enough padding so your number is 25 bytes), keep the high order 21 bytes of this number, compute the double hash of these 21 bytes and append the first 4 bytes of the hash to the 21 bytes. In our example, we obtain 1HeLLoWorLdHowAreYouiAmojzzzzu7udH.

As you can see, this is not quite what we were hoping, as the 'k' Base58 digit of 'iAmok' has been replaced by 'j', due to the interference of the last 4 bytes. We should have chosen a shorter message.

I attach some java code to illustrate the procedure:

import org.bitcoinj.core.Base58;
import org.bitcoinj.core.Sha256Hash;
import org.bitcoinj.params.MainNetParams;
import org.bitcoinj.core.NetworkParameters;
import org.bitcoinj.core.Address;

class Test {
  public static void main(String[] args)
  {

    NetworkParameters main = MainNetParams.get(); // main bitcoin network

    // alphabet is "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

    // This is where we decide what we want to say. The base 58 alphabet
    // does not allow us to use 'l', 'I', 'O' or '0' but that's fine.
    // We are trying to obtain a number which is 25 bytes long with a leading
    // byte of 0x00. So we probably need to start with a leading '1', and
    // we need to add some padding to the right.

    String target="1HeLLoWorLdHowAreYouiAmok111111111";

    // Let us express this number as an array of bytes (big-endian)
    byte[] bytes25 = Base58.decode(target);

    // let us check our number has the correct size
    System.out.println("Size = " + bytes25.length);  // 25 , good

    // let us check the leading byte is indeed 0x00
    System.out.println("bytes25[0] = " + bytes25[0]); // yes it is !

    // retrieving the first 21 bytes
    byte[] bytes21 = new byte[21];
    System.arraycopy(bytes25, 0, bytes21, 0, 21);

    // Let us get the double Sha256 hash of these 21 bytes
    byte[] hash = Sha256Hash.hashTwice(bytes21);

    // Let us create the bytes of the address
    byte[] addr = new byte[25];

    // copying first 21 bytes to address
    System.arraycopy(bytes21, 0, addr, 0, 21);

    // appending first 4 bytes of hash to address
    System.arraycopy(hash, 0, addr, 21, 4);

    // encoding this 25 bytes address in Base 58
    String strAddr = Base58.encode(addr);

    // Address = "1HeLLoWorLdHowAreYouiAmojzzzzu7udH" , almost perfect !
    System.out.println("Address = " + strAddr);

    // let us check address is a valid bitcoin address
    Address address = Address.fromBase58(main, strAddr);  // no errors, good

  }
}


Bitcoin unusable UTXO Attack could be happened?

Technically, sure, this is possible.

Practically, you might get away with it the first time.  You'll have effectively paid an extra $9 for your $40 round of drinks, but you'll get the added satisfaction of having been a jerk.  The bar owner will realize that he can't spend the money, shake his fist, and write off the cost of the drinks (which is probably more like $10).

The next time, you'll find a sign posted that says "Bitcoin payment rules: maximum one output".  If you try your multi-output trick again, they'll point to the sign and say "nope, that doesn't count, you haven't paid".  You'll have to pay again, and now you are out $89 for a $40 round of drinks.

(The third time, you'll find a photo of you behind the bar, marked "DO NOT SERVE".  And a very large fellow in a T-shirt will ask you firmly to take your business somewhere else.)


How many coins are active in Bcash chain

4,636,031 BTC moved on the Bcash side of the fork as of Sept 28th.

4,852,648 BTC moved on the Bitcoin side of the fork as of Sept 28th.

Source: some scripts I run regularly. I intend to create a website with it at some point.


GUIMiner - Don't seem to recognize my GPU. Where to set it up?

It is recognizing your GPU, as "capeverde". ATI has code-names for their GPU revisions, such as Cape Verde, Winter Park, Tahiti, and so on, listed here. Cape Verde matches your model on that list.


Yes, so long as both parties have wallets that support the same specific cryptocurrency - e.g. both support Bitcoin (BTC).

The two parties do not have to use the same wallet software. For example, one might use a bitcoin-core wallet and the other might use an Electrum wallet. It doesn't matter.

Physical location is irrelevant - though local laws may affect parties to the transaction.

Remember that cryptocurrency transfers are usually irrevocable - you cannot cancel or reverse the treansaction if you change your mind or discover that the recipient is a liar, cheat or fraudster.


OpenAssets and CounterParty are the most similar projects I can think of, but I'm sure it doesn't have all of the features you are looking for. You may also be interested in Overstock's Medici project.


How do Bitcoin clients determine the number of confirmations a transaction has?

Transactions are first transmitted to all the nodes in the p2p network.  At this point they are "unconfirmed".
At some point a miner includes the transaction in a block.  The transaction now has 1 confirmation.
Miners continue to find blocks and the next block builds on the block that contains the transaction.  The transaction now has 2 confirmations (the original block + 1 more after it in the block chain).
Miners continue to find blocks, the next block that extends the chain makes the 3rd confirmation and the one after that makes the 4th, etc.

Clients determine the number of confirmations by counting the number of blocks in the block chain since the block that contains the transaction:

"Height of current longest chain" - "Height of chain for the block containing the transaction" + 1


Is a bitcoin address collision possible if generating 90 million addresses every 4 hours?

Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.

Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.

It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.


Do we know which mining software Satoshi used?

"Bitcoin" currently known as "Bitcoin Core". It used to have a miner, which was removed recently (1-2 years) Of course, he used the software he designed.


with bitcoin-cli --wallaet='foo' getbalance

I think you're referring to the -rpcwallet flag.

Usage

The flag changes the endpoint. Try changing the url of the curl call to:

<rpc-url>/wallet/<url-encoded-wallet-name>

Example:

curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": ["*", 6] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/wallet/foo


Error pushing hex of tx, generated with bitcoinjs 1.0, on testnet

Everything is fine with your tx.

Here it is: http://test.webbtc.com/tx/034dfa392aa7ea46bc0917cdaa2794a5f03e6f935b6518a103cb0f5e923a05be

I've pushed it to the network with this form: http://test.webbtc.com/relay_tx


How was the 95% miner adoption threshold determined?

New softforks are activated using BIP 9 (versionbits), which specifies the threshold requirements. The 95% threshold is inherited from the old BIP 34 (supermajority) softfork activation method.

A softfork with greater than 50% hashing power should always become the dominant chain because the upgraded miners will create a harder difficulty chain, and the non-upgraded nodes will be pulled onto that chain because it's still valid for them (soft-forks are backwards compatible). However, any non-upgraded miners may create blocks which are invalid under the new rules. Those blocks will be orphaned off the new chain. The lower the miner adoption rate, the higher this new orphan rate will be.

In reality, as soon as the threshold has been reached and the softfork is locked in, almost all miners will upgrade to the new rules.

The 95% rate is a very conservative threshold to ensure that there is widespread consensus for the new change.

  miners who have not activated SegWit, will still confirm SegWit transactions

This isn't true. If a miner hasn't activated SegWit, then it can't include SegWit transactions in its block (to include a SegWit transaction, it would need to include the witness data and commit to the merkle root of the witnesses in the coinbase transaction). BIP 141 documents all the consensus rule changes for SegWit.


Balance not going up in deepbit after mining

Are you mining with proportional rewards or PPS?

If proportional then you get paid when a block is found. That can take several days at the size Deepbit is now. So things are most likely working, it just takes time.


How were the secp256k1 base point coordinates decided?

Since the secp256k1 curve order is prime, every point on the curve except the point at infinity is a generator.

Nothing is known about how the designers of the curve chose this specific generator.

However, there is one tell-tale sign that hints about its construction. When the chosen generator G is multiplied by 1/2 (i.e. multiplied by the multiplicative inverse of 2 modulo the curve order), the resulting X coordinate is an exceptionally low number. This very likely means that G was created by picking that X, finding a corresponding Y on the curve, and then doubling the resulting point.


Could CHECKSIGADD be used on new ECDSA multisignatures instead of CHECKMULTISIG?

No because the opcode 186 (0xba) is undefined for SegWit version 0 spends. You can only take advantage of this opcode in SegWit version 1 spends. If you included this opcode in your SegWit version 0 transaction script any attempt to spend it would encounter this script error.


How does Nxt agree on a chain when "active accounts" can be easily faked?

Linking to the discussion on the NXT forum https://nxtforum.org/general-discussion/academic-questions-regarding-pos-and-nxt


No. You need the rev*.dat files as much as you need the blk*.dat files. If Bitcoin Core cannot find the rev*.dat, it will need to regenerate them by reindexing the databases. Removing them effectively corrupts the databases.

If you want to save disk space, you can use pruning instead. This will have Bitcoin Core properly remove blk*.dat and rev*.dat files to save disk space.


Bitcoin security, what is wrong with my thinking?

Thats right, if you got the private key you got access to the bitcoins on it. You dont even need to wait until someone starts using this key, you could also randomly find a key which is already in use by someone.

BUT:
Bitcoin addresses are 160 bit hashes of the 256 bit private keys, so there are 2^160 or about 1.460.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000 possible addresses. You will notice thats the possibility is pretty much nil.

For more information you can read this article: http://www.miguelmoreno.net/bitcoin-address-collision/


Can you help me with a puzzle transaction?

So I have resolved the issue, first a huge thanks to pebwindkraft for the direction and link to look at. Based on his breakdown of a transaction I was able to figure out where I was going wrong. I was missing the correct hex to unlock the previous transaction, once that was entered in the correct spot of the serialized transaction, it was broadcasted successfully. The breakdown of the transaction there, plus the bitcoin reference pages were huge helps in figuring this out.

Thanks again,

Dave


Can Bitcoin be run in a shared hosting environment?

bitcoind is a daemon, it needs a shell to run: a web host is definitely not enough.


The potential fork in November does not affect the BCH-chain at all.
Since the new coin does not have a name yet, I will just call it BFC for now.

If you have 1 BTC now you will have 1 BTC and 1 BFC in November.
If you have 1 BCH now you will have 1 BCH and 0 BFC in November.
If you have 1 BTC and 1 BCH now you will have 1 BTC, 1 BCH and 1 BFC in November.

Nobody knows if the new BFC coin will stay like BCH or if nobody supports it (= nobody mines it, it's worth nothing, not listed in any exchanges, ...).


What exactly is generator G in Bitcoin's elliptical curve algorithm?

For a curve with for instance the equation:  y^2 = x^3 + a * x + b

The generator point G, or a ECDSA public key, is a pair of coordinates x and y, for which the above equation holds.

To reduce the storage size for a curve point, one can also store a sign and the x coordinate, this is what is known as point-compression.

You can then reconstruct the y by calculating  sign * sqrt(x^3+a*x+b).

Note that for calculations in modular fields the square root can only be calculated efficiently when the p != 1 (mod 8)


What do the "Fetch Wallet" options when opening a Ripple wallet mean?

"Payward, Local Browser" tries to fetch your wallet from Payward and if an account has not been found or if the Payward is not available / you are offline, it tries to fetch the wallet from local storage.
"Payward" only looks in Payward.
"Local" only looks in local storage.

P. S. You've set where to save your wallet in https://ripple.com/client/#/register right after the "Create Wallet" button.


These are a few options available to Canadians:

Local Bitcoins
BitBuy
CoinSquare
QuickCoin

There are also a few exchanges that accept CAD deposits larger than $100:


Why does Bitstamp allow trading of currencies that it won't return a balance for?

Contrary to the documentation, the server actually returns a balance for LTC, BCH and ETH coins using fields ltc_available, bch_available and eth_available, respectively.


Bitcoin Core frozen trying to sync and/or connecting to peers

Your wallet will need to sync to the network before your funds will be shown as available. This is because the ‘sync’ process involves your node verifying the history of transactions, so the transaction you received cannot be verified until all other preceding transactions have been verified first.

If you think it has frozen during the sync, I’d suggest turning the debugger on, and then looking at the debug.log file for clues on what the issue is.


Which one is more effective for attacking the system, controlling 51% of the mining power or 51% of the full nodes?

51% of mining power would be more effective for attacking the system. if you have 51% of all full nodes, you can't do any attack with your nodes.


The code is free of syntax errors, but it looks like you need to replace the rpcuser and rpcpassword in this line:

h = BitcoinRPC.new('http://rpcuser:rpcpassword@127.0.0.1:8332')

To the actual rpcuser and rpcpassword values that are set in your bitcoin.conf file.

If that doesn't work, I'd suggest doing some debugging by opening an irb session and running this code to see the result of the HTTP request to the RPC service:

require 'net/http'
require 'json'

post_body = { method: 'getblockchaininfo', params: [], id: 'jsonrpc' }.to_json

uri = URI.parse "http://rpcuser:rpcpassword@127.0.0.1:8332"

def http_post_request(uri, post_body)
  http    = Net::HTTP.new(uri.host, uri.port)
  request = Net::HTTP::Post.new(uri.request_uri)
  request.basic_auth uri.user, uri.password
  request.content_type = 'application/json'
  request.body = post_body
  http.request(request).body
end

http_post_request(uri, post_body)


http://blockchain.info/charts/market-cap. 24 hour Weighted price from mt.gox and tradehill.


How can I fix corrupted encrypted wallet.dat?

Found out that pywallet has recovery feature, and it worked:

Created 1GB FAT32 partition on flash drive(/dev/sdb1 in my case), copied corrupted wallet.dat on it and run:

nyaa@ubuntu:~/github/pywallet$ sudo ./pywallet.py --recover --recov_device /dev/sdb1 --recov_size 1Gio --recov_outputdir /home/nyaa/
...
All the found encrypted private keys have been decrypted.
The wallet is encrypted and the passphrase is correct

One of change addresses with all bitcoins on it was there!


Is a mining program necessary for mining, or can bitcoind mine by itself?

The daemon can do mining using the -gen command line option, but it's CPU mining and is impractical nowadays.

Using a separate mining app is practical. That separate mining app connects to a running bitcoind via its JSON-RPC API in order to facilitate getwork or getblocktemplate requests necessary for hashing.

The JSON-RPC API is configured in bitcoin.conf or at the command line using these arguments:

-rpcuser=<user>        Username for JSON-RPC connections
-rpcpassword=<pw>      Password for JSON-RPC connections
-rpcport=<port>        Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
-rpcallowip=<ip>       Allow JSON-RPC connections from specified IP address


Is it more efficient to use multiple computers when I have multiple GPUs?

This is a question of efficiency regarding MH/s. Simply, I would like to know which is better

It doesn't matter. Every hash has an equal probability of finding a block. However, that being said, there's some hidden teeth:

Putting graphics cards together will make them harder to cool.
Putting them in multiple computers will use more electricity - all computers use some electricity, even at idle.

  Could the answer please include efficiency for both solo mining and pool mining?

My advice applies for both.


Does getrecievedbyaddress work for all addresses?

No, it only works for wallet addresses. You can add watch-only addresses without key via importaddress, though.


That's just a bitcoin address, it may not have any bitcoins sent to it, and even if it does, you can't spend them unless you find the private key too. Check the balance of that address here https://blockchain.info


Bitcoin exchange platforms and foreign exchange regulations

There's basically no way to answer this in a way that's general to countries that forbid foreign exchange, because these regulations have different goals in different countries.

For example, in Venezuela, all foreign exchanges must go through a state bank. The purpose of this is so that they can pretend that their currency is worth more than it actually is. If the central bank in Venezuela doesn't deal in the currency of your choice, I don't think you have any sort of recourse.

I don't have any advice for you, besides, "Hire the nephew of the guy who runs the central bank in your country."


Given that contracts can be formed in the blockchain using scripts, couldn't a contract include a mechanism for facilitating chargebacks?

You could use 2-of-3 outputs to do this, where the third key is held by a trusted mediator.

A merchant could consider himself paid when the 2-of-3 transaction is confirmed. In the normal course of events the 'chargeback period' would expire and the mediator and merchant would send the money to the merchant's normal address.

If the customer requests a chargeback before that, then either the merchant would agree or the mediator would step in and perform the chargeback according to whatever policies it sets.


blockchain.info and blockexplorer.com show different balance for the same address

Their definitions of 'total received' differ in that blockchain.info does not count change outputs as an amount 'received', whereas most other explorers do (since there is no way in general to determine if an output is really change or not, unless change is sent back to the sending address, which is the case for blockchain.info wallets).

See this related post on reddit.


Generally speaking, decentralized markets such as LocalBitcoins and BitSquare have the money onchain as they facilitate exchanges directly between users, and centralized markets that take custody of the money prior to trading have the funds offchain as otherwise the transaction fees they're spending would be much higher.

I think that in the past Coinbase and Kraken both kept user deposits in separate addresses for each customer.


How Ripple is different from Bitcoin and other crypto-currencies?

There are several major differences. Bitcoin is a currency with a built in payment system for its currency. The XRP Ledger is a payment system for arbitrary currencies with support for cross-currency transactions.

One big difference is that currencies (other than XRP) are represented as debts (IOUs) on the ledger. This is much the way currencies are represented in the conventional banking system. When you say, "I have $5,000 in my bank account", what you mean is that the bank owes you $5,000. When you write someone a check, you are transferring debt so that their bank owes them more money and thus they consider you to have paid them. Ripple works this same way -- payments occur by a transfer of debt (IOU).

You can generally get a Bitcoin transaction through for free if you're patient. XRP Ledger transactions always have an XRP cost. In practice, this cost should remain very low. Transaction fees are destroyed on the XRP Ledger, they aren't paid to anyone.

XRP Ledger payments that use assets other than XRP can incur fees other than transaction fees. It is hoped that competition will keep these costs low. If your payment requires using someone else's liquidity, they can impose a fee for that liquidity. IOU issuers can impose fees on transfers of IOUs.

XRP Ledger transactions should confirm more quickly, typically in under 10 seconds.

While the XRP Ledger is designed to operate without a central authority, currently almost all validating servers are operated or managed by Ripple Labs. So it's not fully distributed yet in that sense, but it will be. Currently, most XRP (the units used to pay transaction fees) are held by Ripple Labs.

It is also important to understand that using the XRP Ledger as a store of value for fiat currencies imposes a counter-party risk. If you hold dollars on the ledger, someone you have chosen to trust owes you those dollars. If you misplace trust, you can wind up with uncollectable IOUs.

The ledger can uss gateways, companies that make it their business to make "settle on demand" agreements with people, to hold IOUs. The ledger is much less useful for payments of fiat currencies if there aren't reliable gateways you can trust to hold your money.

In function, the XRP Ledger's way of handling assets other than XRP is more like PayPal or Visa than Bitcoin. But its internal implementation is based on the same technologies Bitcoin uses -- public transactions, no central authorities, cryptographically secured transactions, peer-to-peer transaction propagation, and so on. One key difference is that people who choose to use assets issued by different counterparties can seamlessly exchange value with each other through a distributed exchange. So there's a huge interoperability benefit.


I'm afraid this is how Bitcoin works, and there is little we can do about it. Think of it like a bank transfer you initiate on a Friday, it has to be processed by the bank at some point in time, only banks do not settle transactions during weekends, and large backlogs will further delay the processing. Now replace the centralized bank, with the Bitcoin blockchain. While it does not have holidays, it does have to deal with backlogs.

In times of a large number of transactions hitting the network at the same time the backlog grows, and this has been the case for the last few days, since the network's capacity is lower than the influx of new transactions. You can get ahead of the queue by adding more fees to your transaction (try looking for RBF or CPFP), but in order for the backlog to be reduced we need some time (usually weekends) when the capacity of the network exceeds the influx of new transactions.

We can also not retract transactions, since that in itself would be another transaction that needs to be processed, and even worse, all nodes in the network would have to agree to discard the transaction, which is in itself a consensus problem, which is why we had to come up with the whole blockchain business in the first place.

So, while it certainly is frustrating having to wait for confirmations, it'll eventually confirm, and you can influence your position in the queue by adding more fees, replace-by-fee, or child-pays-for-parent.


Seemingly random transactions on testnet

Testnet is generally pretty noisy, filled with strange transactions and nonsensical movements of money. I personally hold wallets responsible for 20%+ of all transactions in the block chain, and most of the UTXOs. If you want a stable environment regtest is designed for testing your tooling without the noise or needing to wait for blocks.


i sent bitcoin from my coinbase account to my bittrex account but i used the Bitcoin cash address on accident

You can try contacting Coinbase and/or Bittrex, however when you open your bitcoin cash wallet on Bittrex it clearly says, "Depositing tokens to this address other than BCH may result in your funds being lost", so there's no guarantee.


Receiving payments in Bitcoin for RESTful API calls

There is one: https://github.com/Overtorment/Cashier-BTC/

Disclaimer: coded by me.


Can I see the address of my direct peer?

First of all, nodes do not necessarily have an address, nor do they necessarily have just one. Addresses are not identities and are not tied to nodes. A node operator can operate a node without a wallet, so that node does not have any addresses. A node operator could have a wallet on their node that has many addresses, that node would have many addresses. So this idea that each node has an address is itself incorrect.

For nodes that do have wallets, the wallet and the node basically operate separately. The node part (handles P2P, tx and block validation, etc.) does not know the contents of the wallet. It does not know what addresses are in the wallet and what transactions actually belong to the wallet. So no, the node cannot directly reveal the addresses for its associated wallet(s) as it does not have access to that information.

The only way you would learn what addresses belong to a node are by observing the transactions that it sends. But in order to know what transactions it truly sends, you need to surround that node with nodes that you control so that you can control/observe everything that that node learns about and sends. When it sends a transaction, it will be a transaction that was not relayed to it by one of your nodes surrounding it so you know that transaction originated from that node and then you can do other blockchain analysis techniques on that transaction to learn further information. This kind of attack is known as a sybil attack.

Another related attack is to connect to every single node on the network and see which node first relays a transaction. However this is basically impossible to do. There are many non-listening nodes so you wouldn't be able to connect to them. Additionally due to latency and physics, this is not as reliable as your node(s) could learn the transaction from a relay node instead of the direct connection to the originator if there is too much latency on that direct connection.

However performing these attacks is not easy. Nodes have active countermeasures to make these attacks more expensive and increase their own privacy. These attacks can be fairly costly and there is no real monetary gain from learning this information.


Is it possible to configure bitcoind to allocate blocks in larger "chunks"?

If you referring to the blkxxx.dat file it will always have a maximum size of 128 MB which is defined in the bitcoin the source file validations.h

static const unsigned int MAX_BLOCKFILE_SIZE = 0x8000000; // 128 MiB

Also in this file you can see that the maximum pre-allocation chunk size fixed.

static const unsigned int BLOCKFILE_CHUNK_SIZE = 0x1000000; // 16 MiB


What was the original rationale for limiting the maximum push size?

This limit is long standing and unexplained, but it didn't always have that particular name. It was dubbed MAX_SCRIPT_ELEMENT_SIZE in this commit, where previously it was just a magic number in script.cpp. The restriction is found throughout the entire history from master until 0.3.22, but is missing from the 0.1.3 source. You could speculate that it was intended to be an anti-DoS restriction, but these releases retained OP_CAT which would have allowed for nearly infinite sized stack elements regardless of the sizes of data pushes.

The 520 byte push size severely stunts Pay to Script Hash, as the entire script is pushed onto the stack it must respect the push limit. For a P2SH multisignature script this sets the upper limit to n-of-15, any larger and it would be unspendable due to 520 byte consensus rule.

Increasing this limit would be a hard forking change.


What's the purpose of running Armory through Tor?

Armory (in online mode) uses a full node.  Full nodes relay transactions for other programs on the Bitcoin network, so by running Armory on Tor, you help other people send their transactions with possibly-improved privacy.
Sending your own transactions through Tor with Armory can help prevent anyone from associating your IP address with your transaction, possibly improving your privacy.

Note: Tor and Armory must both be used properly to achieve improved privacy.


Antminer U3 not detecting in cgminer nor bfgminer?

From BFGMiner's README.ASIC file:

  The U3 does not support autodetection, so you will want to use
  --scan-serial to manually probe it. For example, to scan all devices, you can use:

  -S antminer:all --set antminer:chip=BM1382

  Additionally, for optimal performance you will need to set voltage,
  clock, and timing. Voltage format for the U3 is not documented by the
  manufacturer, thus must be provided as hexadecimal configuration
  codes. Timing is provided in the number of nanoseconds each hash takes
  at the given configuration. A known-working configuration is:

  --set antminer:voltage=x800 --set antminer:clock=237.5
  --set antminer:timing=0.022421


Duplex micropayment channels: criticisms of Lightning and implementation

As of today, (November 2018):

  To what extent are those criticisms of Lightning valid as of November 2017?

This is still a case for Lightning. Eltoo was the first to suggest a simpler way of coping with such storage requirement. They do not require storing keys or older transactions. Their disadvantage is that there is no punishment in the event of fraud, leading to selfish users always publishing the transaction that maximises their balance. In current Lightning Implementations, it is important to keep track of Breach Remedy Transactions, and of course never lose new Commitment Transactions (as this can incur in a punishment to oneself after publishing an old balance unknowingly).

  Is there an implementation of Duplex micropayment channels or at least plans to create one?

Current implementations are focusing in Lightning Channels for two main reasons:
1. Eltoo channels are too recent (perhaps somebody is working publicly in an implementation, I am not aware)
2. DMC channels have a trade-off between the utility of the channel and the worst-case collateral cost of the channel, that discourages its use. This is even more important when considering n parties (such as factories). For more information about this trade-off, see the results in this document

DMCs are however better when one knows of a period of time that one will be offline, so I believe it will be implemented in the future. But there is no current implementation in the main ligthning development teams.


Vanitygen: How ot store all generated addresses?

./vanitygen -k 1 -o output.txt

will generate addressses until you stop it, and will save the addresses to output.txt. It won't be formatted, so it's a better idea to use Vanitygen Plus's -z option, which formats the output as CSV.


Bitcoin mining, do you do the work or does the computer?

The extent of human involvement in mining is to get the software and hardware and then run the software on the hardware. No one actually has to sit at a computer and do anything in mining. They don't even have to come back and check on anything as all aspects of mining are automatic save for computer setup and maintenance.


is there a way to allow the user to import his existing wallet into my app

That looks a bit like this API function:
https://www.blockchain.com/api/blockchain_wallet_api says

Create Wallet API

Create blockchain wallets programmatically
The create_wallet method can be used to create a new blockchain.info bitcoin wallet.
URL: http://localhost:3000/api/v2/create
Method: POST or GET

$password The password for the new wallet. Must be at least 10
characters in length.
$api_code An API code with create wallets permission.
$priv A private key to add to the wallet (Wallet import
format preferred). (Optional)
$label A label to set for the first> address in the wallet. Alphanumeric only. (Optional)
$email An email to associate with the new wallet i.e. the email address of the user
you are creating this wallet on behalf of. (Optional)

Please create an API code here including permissions to "Create Wallets".

Your app can read an existing wallet file, extract the private key (or keys) and use this function to create blockchain wallets containing those keys (and hence allowing the spending of all money "in" that existing wallet file)
Maybe there is some feature of this that you find unsuitable - but haven't explained fully why?
It is not unusual for businesses to require a different arrangement with merchants using their services commercially as a back-end. Whether your use might fit into this category is unclear, but a read of the Terms & Conditions for commercial use of their service might clarify this.


In BitcoinJ, do I need to run downloadBlockChain() again after adding a new key?

Yes. You must call clearTransactions(0) on the Wallet, followed by downloadBlockChain() on the PeerGroup.

BitcoinJ is a thin client, meaning it doesn't download transactions for addresses that aren't in its wallet.

https://bitcoinj.github.io/working-with-the-wallet#replaying-the-chain


The answer you linked isn't wrong; you just stopped reading too soon.

Transactions aren't signed by the master private key itself; they are signed by the child private keys.  But those child private keys were generated from the master private key.  So it's true that all you really need to store is the master private key.

If you have the master private key, and you want to sign a transaction, you don't sign it with the master private key directly.  Rather, you first use the master private key to regenerate child private keys until you find the one that matches the address you want to spend from.  Then you use this child private key to sign the transaction.

For day-to-day use, it is convenient to store the child private key after generating it, so that you don't have to go to the trouble of regenerating it each time.  But for backups, all you really need to save is the master private key.


Help With Raw Transaction Fee - Absurdly High Fee

The fee of a transaction is just the difference between the input and the output value. In the second transaction you posted, the input value was 0.25 LTC and the output value was 0.15 LTC, so you paid a 0.1 LTC fee (0.25-0.15) as you say. If you choose an input which is larger than the output you want to send as well as the fee, you have to create a change output to send the rest back to your wallet as well, otherwise it will all go to the miners as fees. For example, if your input was 0.25 LTC, and you wanted to send 0.15 LTC and only pay 0.01 LTC fee, your transaction would need to have two outputs, one for 0.15 LTC, and one for 0.09 LTC back to an address you own, so that the total fee is just (0.25-(0.15+0.9) = 0.01)


When we're calling `getrawtransaction` how does Bitcoin-core calc and verify confirmations?

First of all, multiple confirmations does not mean that a transaction or its hash is included in multiple blocks. One confirmation means that a transaction was included in a block. More than one confirmation means that blocks have been mined on top of the block containing the transaction.

So what Bitcoin Core does is it records the hash and height of the block that contains the transaction, subtracts the current main chain height from the block height and then adds one. This counts the number of blocks mined after the block containing the transaction and then counts the block itself. This results in the number of confirmations the transaction has.


How to verify signature of multisig transaction

There is no way to check the transaction separately for each signature. Either the entire transaction is valid or it is invalid. When you receive the partially signed transaction, you would need to sign it with your own private key using the signrawtransaction command in bitcoind. It would give you two outputs (1) hex which is the serialized transaction and (2) complete. If the second output shows you "complete": true, then the transaction you received was signed with a valid private key. If it shows false then it wasn't.


Difficulty is a measure of how difficult it is to find a hash below a given target.

The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.


Can separate Bitcoin chains be merged back?

No it's not, it must be a blockchain not a blockgraph, if two blocks share the same parent then only one of them can be in the chain, and because blocks can't be 'editted' without simply remining them, you have to choose either one chain or the other. Even if you could, do that, there's a host of other issues like the same coins being spent on both chains, or the block height in the coinbase being wrong


What encryption does Electrum use for private keys in wallets?

Electrum uses AES-256-CBC to encrypt wallets.  The key is sha256(sha256("your password")).

Electrum wallet source:
https://github.com/spesmilo/electrum/blob/master/lib/wallet.py

slowaes library:
https://code.google.com/p/slowaes/source/browse/trunk/python/aes.py


Is the bitcoin blockchain really non-corruptible?

Your attack wouldn't work because nodes take the most-work chain as leading, the number of blocks is irrelevant. Any attacking chain needs to spend at least as much work as was done for the original. This actually used to be a bug in the whitepaper and the initial bitcoin software implementation: it checked for the longest chain instead of most-work. It was fixed very early on.

Checkpoints are centralizing as they give devs power. They're no longer done in Bitcoin.


Do I need N confirmations if I'm only worried about the transfer getting invalidated by a different block?

A transaction can only be invalidated by an attempt to double-spend. That is, the same transaction can be in block X or block X+1 or block X+n as long as there is no double-spend associated with it.

If you want to make sure that a transaction goes into a block soon-ish, try to add a fee that's sufficient to make a miner want to add it to a block. In that case, you only need a couple confirmations as being an orphan block after that is exceedingly unlikely.


What files one should backup when running a pool or other Bitcoin service?

You need to back up your wallet.dat regularly. If your pool uses "getwork" for generating work and later generating blocks, then each block is generated with a new crypto key. Also, when you send coins out to pay your miners, the "change" is always sent to a new address. So your bitcoind is always generating new crypto keys, and you must back them up so you don't lose any coins.

So any bitcoin service that sends coins or generates new blocks with "getwork" must back up wallet.dat regularly. A bitcoind that only receives coins can be backed up only once. A bitcoind that doesn't handle coins obviously needs no backup (rare case, but can be useful).

Apart from that, of course back up your database and anything else you don't want to lose.

Update: I just want to add that bitcoind has a pool of unused keys. It makes new keys when the pool runs out. Most of the time it just takes fresh keys from the pool - and you backed those up. So you don't have to run backups once per minute to be safe. If you want to do this the best way possible you could give bitcoind the "keypoolrefill" command (and wait for that to finish) before backing up wallet.dat. This way you always back up a full pool of unused keys, and the backup will "last" as long as possible. That is to say, it will take as long as possible before the pool runs out and bitcoind generates new keys for the pool that you don't have in the backup.

There is some info on the key pool here: https://en.bitcoin.it/wiki/Key_pool.

Update 2: I'm actually unsure if "keypoolrefill" only has an effect if you resize the keypool. If you don't change the size of the pool, I think bitcoind generates a new key for the pool each time it takes a key out of it. Someone correct that if it's wrong.


Transactions not showing up in bitcoind log?

Use walletnotify instead of polling.

how to do address callbacks?

It's basically a argument you can specify and Bitcoin will the specified program upon receiving a transaction (BOTH receives and sends from an address in wallet get notified). So you just setup a small script to run and point to it in bitcoin.conf.

Be sure to check for duplicates as walletnotify sends notifications for when a txn is first received (unconfirmed) and when it receives a confirmation.

Also blocknotify does the same thing as walletnotify but for blocks, may be useful for checking unconfirmed transactions.


How to get the last executed transaction?

The first transaction in the list should be the newest one.

The best way to answer such questions is always to read the source code. getTransactionsByTime calls getRecentTransactions, and there is a comment:

  Returns an list of N transactions, ordered by increasing age.

You can trace down to find the critical minus sign that ensures this.

You can also find a test that explicitly verifies it works as documented.


Calculating fee based on fee rate for bitcoin transaction

There are some improvements that you can make to this algorithm.
The first is to select UTXOs based on their effective value. The effective value is the value of the UTXO with the amount in fees required to spend it subtracted from it. In this way, each UTXO you spend pays for itself. This is called the effective value because that is the value that actually affects the outputs. You do this by calculating how large spending that UTXO will be, then multiplying by your fee rate to get its fee. This fee is then subtracted from the UTXO amount.
Then you can calculate the fees for the rest of the transaction, i.e. the fixed overhead (tx version, locktime, etc.) and the outputs. Since these are all determined before you choose the UTXOs to spend, it's fine to calculate this value before you choose UTXOs. The UTXOs you choose won't have an effect on this fee. This amount in fees can then be added to the amount you are trying to select for, i.e. add it to the amount being sent.
By using the effective values of inputs (so inputs pay for themselves) and then increasing the amount that you are trying select (so the cost of the rest of the transaction is covered), you can remove the need to loop (step 7) in order to choose the UTXOs you want. Now when you choose the UTXOs, you know that each input has paid for itself, and that you have chosen enough value to cover the outputs and their cost.
Another improvement is to not sort the UTXOs. In fact, it is better to choose UTXOs randomly. You can achieve this by shuffling the list of UTXOs instead of sorting them. Sorting UTXOs has several longer term effects that will negatively impact you in the future. Notably, by sorting UTXOs, you will end up creating very small change, which means that future transactions will have many UTXOs with small values, which increases their fee. Sorting by smallest first will see this effect sooner. Sorting by largest first will see this effect over time.


How many addresses does bitcoind use for Bitcoin generation?

Each block reward will be credited to a different address. No more than one address per block is used in the generation process.


Why can't I withdraw any BTC from MtGox?

When Mt. Gox initiates the demand for verification your account is essentially frozen for withdrawals until you send in the required identification (color photo ID and whatever else they want) and your account gets verified.

The instructions from the link you provided will clearly state what is needed.

For example, it might state

  VALID Photo ID Proof (Identity card, license, passport,...)
  Residence Proof (utility bill, tax return, insurance,...)
  ISSUED WITHIN 6 MONTHS

For the color photo ID, even a pic of the ID taken with a phone is usually sufficient.


10 bitcoins are worth $60,000 dollars. How can this be?

Indeed, the price has skyrocketed recently, each bitcoin is worth around $6092.00 USD as of writing this answer, it's not a glitch.

  I am tempted to cash it out but feel this is illegal and the goverment is going to be on me.

It's not illegal to sell or buy bitcoins in most countries, see: https://en.m.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory
You should probably just ensure you pay tax on the income.


Are the Thin clients Electrum and Multibit safe and secure?

Currently, Electrum is more secure than MultiBit as the MultiBit wallets are not encrypted. The next version of MultiBit, version 0.5.9, supports encrypted wallets. (Disclaimer: I am the lead MultiBit dev)

Security in Bitcoin is related to many things. Here are some of them:

1) Is the code open source and do the developers have a track record ?
Both Electrum and MultiBit are open source so you can inspect the code. They have both been developed by pretty much the same people for over a year now.

2) Can you verify that the download you get is the correct one ?
The attack vector here is that an attacker substitutes a trojan instead of the real installer.
The MultiBit installers are all downloaded from a dedicated server via HTTPS and are signed with my PGP key. You can verify this after you download the installer (but before you run it). As long as my private key is not compromised this means only I could have signed it.

I am not exactly sure what Electrum does about signing its builds but I know Thomas (the lead Electrum dev) is very conscious of this area/ attack vector.

3) Are there any servers that can steal your bitcoin ?
MultiBit uses the regular Bitcoin network and they don't have your private keys. Electrum uses (many) of its own custom servers but again these do not have access to your private keys.

4) Both clients are theorectically open to an attack if their network connection is owned and the attacker can feed them completely false information.

5) Both clients (well every client in fact) would be vulnerable to keyloggers capturing passwords which (in combination with the encrypted wallet in MultiBit's case) would give an attacker access to your private keys.

tl;dr At the moment Electrum is more secure. When MultiBit supports encrypted wallets they will be comparable. Good security practices on your machine are also important to keep your bitcoin safe.


Is it possible for the miners to collude to blackmail a single wealthy address?

I think your update changes the question significantly (probably too much for a SE question), but the answer is still essentially the same. In order for a miner to prevent a specific address from moving their BTC, they must not only decide not to mine the transaction but they must also convince at least 51% (most likely more) of the hashing power to not only not mine the transaction but also to ignore any block that does include that transaction.

First of all, I think that this is highly unlikely. Because:

Any combination of entities with >51% of the hashpower also has a very vested interest in Bitcoin. And deliberately allowing extortion would be against the interests of Bitcoin.
Any combination of entities with >51% of the hashpower has other potential ways of exploiting the network, which are arguably a lot more profitable.
The bribery incentive you list wouldn't really work. There's too much anonymity in the system. If you had an address that would give me back 110% of what I sent it, I would send it some money, launder the results into a new address, send it some more money from that untainted address, send it some more money, rinse and repeat.
Even if the "cartel" has 55% hashpower, there is a 1.8% chance that the minority miners could get six consecutive blocks mined. This may not sound like a lot, but if the extorted party just kept pushing trasactions out there it would only be a matter of a few hours before one of the transactions got six confirmations. So, the cartel would either have to be willing to break long strings of blocks (completely putting the network in jeopardy) or they would have an overwhelming supermajority of the hashpower (>90%).

So, in answer to your subquestions:

Is it illegal? Well Bitcoin doesn't have laws. If you mean, "would the protocol allow it?" Sure. A known weakness of the protocol is that if any entity controls a majority of the hashpower then there are some attacks they can make. Luckily there are some checks on this, notably the above comment: that anyone with a majority of the hashpower also has a lot invested into the health of the network. The deliberate limiting BTC Guild did on itself a few weeks ago shows this in action: the very entities that could obtain 51% hashpower are the ones most interested in making sure that no one obtains 51% hash power.
How would it be detected? In your modified scenario, it would be public knowledge. But even if someone tried to build a silent conspiracy, it would be pretty easy to detect if they went through with their threats: there would be orphaned blocks. And all of the orphaned blocks would share two things in common: they would all contain the extorted address and they would all be mined by minority miners. It would be pretty easy to figure out what is going on. Of course, you couldn't stop someone from secretly making threats, but detecting someone carrying out the threat would be easy.
How could it be resolved? Fundamentally the network is controlled by a majority of the hash power. If a supermajority of the miners decided to block an address, then there is no resolution: the majority rules. In a way, this is a feature. No one with the majority of the hash power would do this indiscriminately: it would jeopardize the network. But if the network determined that a particular address or addresses was a threat to the network, then the miners could band together and defend the network from that threat.

To expand on #3 with an example, say that a child pornographer publicly advertised some kind of service and accepted Bitcoin as payment. If, either out of altruism or media pressure, the majority of the hashpower decided to forbid payments to or from that address it would certainly be possible. (Of course, it would then become address "wack a mole", but there are some ways around that if the network could agree.)

TL;DR: The point being that if the miners collectively agree on something, yes, it is possible to effectively control the network. By design. That includes rolling back to a previous version (such as in the fork of March), preventing a theoretical exploit, or even executing a theoretical ban. But it's unlikely that a coalition would be willing to use that power for extortion. The miners have too much at stake in the health of the network.

Update:
I discovered something to add while researching something else. Satoshi made the commment that if transactions are deliberately being dropped that it could be addressed client side by coding the standard client to ignore blocks that they know are ignoring transactions. It was in a slightly different context in that thread, but the gist remains the same. If a majority of the miners colluded to exclude an address, there are some client side ways of giving favor to the "honest" miners, assuming that a majority of the client nodes were willing to upgrade to a version that protected again this.


Calculate tx fees before sending with sendtoaddress

If you call

bitcoin-cli settxfee <fee>

just before call

bitcoin-cli sendtoaddress "1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N" <value>

Then the fee will be <fee>.

Important note: make sure in the graphic mode (when you start with bitcoin-qt command) the "custom" is selected, otherwise your command settxfee will be ignored (see image bellow).

Also, I'm not sure if this option is selected by default, and I am not sure as well if it you can set "custom" via API. If someone knows that, please edit this answer and fix it.

Note 2: I'm not sure if this is strictly necessary, maybe not. I didn't make many tests. The test I made was starting bitcoin with bitcoin-qt -txindex -server & and then letting the interface open. If "recommended" is selected the command settxfee will be ignored. I didn't tested e.g. what if let the "recommended" option selected, close the interface and then start with bitcoind -txindex for example.


Can someone explain to me how do you read the blockchain.info transaction data?

Bitcoin addresses on the left are valid addresses from wallet, someone has private key for them. Bitcoin addresses on the right can be any addresses, even addresses, that nobody has private keys for them (so bitcoins on them are unspendable).
This is transaction id.
Bitcoin transaction can have many addresses on the left and on the right. Bitcoins are moved from left addresses to right.
You opened a page with specific address. $1453 means, that this address received $1453 with this transcation. If you open a page with this transaction directrly https://blockchain.info/tx/7dd8efe094e11c890eea7dc65e9bc7fb44903ed3e9b856e854d7d31e247ea1f2 you can see total sum. If you sum up left part and substract sum of right part, you can calculate fee.


What are the possible Version Bits votes?

Most of what you ask about doesn't have anything to do with Version Bits actually. :)

Let's start from the top:

nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on it was required that all blocks have a version number equal or bigger than two. Expressed in binary, two is 0010. Since the version field is little-endian, this meant that going forward it was thus required that the first three bits in the version field had to be 001.

BIP0009: Version Bits introduced the idea of interpreting the remaining 29 bits as flags instead of interpreting the whole field as one integer. It's also less of a vote but rather a signal of readiness for a softfork proposal. The readiness is expressed by setting the respective bit to 1 in the version field. (More rules for using Version Bits are specified in BIP0009.) It is thus possible to signal readiness for up to 29 softfork proposals at the same time. Therefore each Version Bits field corresponds to signaling about all softforks currently in deployment.

Out of the proposals you list, only SegWit uses Version Bits for deployment: List of version bit deployments. None of the other mentioned proposals is a softfork, and they don't make use of Version Bits for deployment. Instead, they communicate support by setting the Coinbase text.


What bad things could happens if Bitcoind RPC is public?

Recently ELectrum had that bug, First of all, if your wallet were not encrypted you will lose your funds and that is the most dangerous thing might happen.

If safe mode is enabled disablesafemode=1 You will avoid any danger RPC Calls.

  Safe mode is a feature that disables a subset of RPC calls - mostly
  related to the wallet and sending.

If you want to make your server public, Enable safe mode and disable wallet access.


How does a blockchain relying on PoW verify that a hash is computed using an algorithm and not made up by a human?

A Hash Function maps "data of arbitrary size to fixed-size values". As an incredibly simple hash, consider a function only works on numbers and simply returns the last 3 (decimal) digits (ie., the 1s, 10s, and 100s places).
Using this simple hash, 5 would hash to 005, and 123,456 would hash to 456.
A Bitcoin block contains a handful of fields (source):

Version
Previous block hash
Merkle root
Time stamp
Difficulty bits
Nonce

All of those can be represented by numbers (the time stamp is Unix time (source), which means it's basically the number of seconds since 00:00:00 UTC on 1 January 1970).
Of those values, only the nonce can be freely changed without invalidating the block. The timestamp can take a range of values (roughly "1 hour ago" to "2 hours from now" (source)), and the version number has a great deal of flexibility (ibid). I'll focus on the nonce since that's the easiest for me to talk about.
Proof of work, in this simplified scenario, is accomplished by adding all of those numbers together and finding a nonce that results in the hash being 000. In this simplified scenario, that's trivial to do: you can just add the other numbers together, hash that partial sum, then set the nonce to 1,000 - that partial hash. So, it's not a very good hashing algorithm for this purpose.
Instead, Bitcoin uses SHA256. SHA256 has a couple of advantages which stem from its being a cryptographic hash function; the big three are that calculating the SHA256 hash of a given value is "cheap" but generating a value that will produce a given SHA256 hash is hard, and that tiny changes in the input will produce large changes in the output (the avalanche effect).
In fact, to the best of our collective knowledge, the only way to generate an input that produces a given SHA256 hash is to keep trying inputs until you find one that works.
So: unlike the simple hash at the beginning, we can't figure out what the nonce should be just by looking at the rest of the data. And, we can't just tweak the nonce to get the hash we want: the avalanche effect means that every small change to the input will have large changes to the output. Therefore, the only way to find a nonce that produces a valid SHA256 hash is to start at 0 and work up 'til a suitable nonce is found.
Once a suitable nonce is found, anyone can verify that the nonce/hash pair is valid by hashing the block with that nonce and seeing that the hash matches. This check can be done very quickly, and serves to prove that whoever found that nonce did the work.
The nonce is a 32-bit integer (source), which means that there are 4,294,967,295 (just under 4.3 billion) possible nonces. Compare that to the Powerball lottery, in which a single ticket has about a 1-in-300,000,000 chance of winning the jackpot, and it becomes clear how unlikely a randomly-chosen nonce is to be valid; even if there were thousands of nonces that could produce a SHA256 hash with enough leading zeroes, picking nonces at random would still be staggeringly unlikely.
Then, the time can take any value in a roughly 3-hour window and has second-resolution, so there are ~10,800 values it can take. The version has some limits, but it appears to be another 4-bit integer like the nonce; for rough calculations' sake, let's say it can take half of the possible values that the nonce can. That means that there are around 9e+22 (a 9 followed by 22 zeroes) possible combinations. There are about 200 billion stars in the milky way (source); that is, 200,000,000,000 or 2e+11. Finding a correct header randomly had odds in the realm of two people randomly choosing the same grain of sand from the whole of the galaxy.


Is there a Bitcoin price alert application that can use data from BitcoinCharts.com?

The wiki maintains a list of currently available software tools.

I don't see anything on there per-se but it might be an included feature in one of the pc tools.

But I say go ahead and write one if you have the time and desire.  It's nice to have options even if that feature already exists somewhere. I'm mostly Mac desktop guy these days so I'm a fan of multi-platform tools when possible. But that's tough to do for the kind of thing you're taking about. But if you open-source it there's always room for someone to port it or expand upon it!


Unknown factor in bitcoin pool breakdown

It is unlikely that we will account for most of the activity, as Bitcoin allows for high anonymity. Some of that hashing power is believed to come from some botnet, but one can't be sure. You could try looking for the owners of the IPs that relay the new blocks and check who they are, but that would be a tedious work that could be easily hidden, for example by relaying blocks through TOR.


blockchain.info transaction timestamps set into the future

1) Are these valid transactions?

Yes

  2) If they are valid, how can I assign a valid timestamp to these
  transactions? Would it be 'fair' to simply assign them the block's
  timestamp?

You can do anything. Yesterday I've timestamped them as 1905, today as 2048

  3) From what I understand about the Received Time, it represents the
  time that bc.info sees the transaction, so how can this this timestamp
  be occurring? Is it a bug?

Yes.


How to check if one transactions is from the same wallet (public key) as a previous one

If the transaction in question consumes inputs that were locked to a bitcoin address that has been previously used, then it would be easy to tell that the payment came from the same wallet. After all, the payment came 'from the same address' as a previous payment.
However, re-using addresses is not best practices. Doing so is very bad for your privacy, just consider the premise of this question to understand why! There is no reason to re-use addresses and thus allow someone to see your financial history (ie, all of the other transactions you've made from that address).
Thankfully, modern wallets are built to never re-use addresses. Further, addresses from the same wallet are indistinguishable from random addresses, there is no public information included in the address/transaction that links them together. This is by design: you wouldn't want someone to be able to determine your entire wallet balance, after receiving a single transaction from you.


What is the difference (or relation) between a Bitcoin "Block" and a GPU workunit called a "Block"

No, these two terms are completely unrelated.

Bitcoin block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks.

GPU block is just an unit of organization of threads running in parallel. The threads running on GPU are organized in blocks, and threads belonging to same block have effective means of interacting with each other. The size of single block and number of blocks affect application performance, and optimal parameters differ between different hardware. Surprisingly, while most GPU miners are written in OpenCL and not in CUDA, the 'block' term comes from CUDA and OpenCL specs use 'workitem' to refer to this concept.


Privacy of sending CoinJoined UTXOs from wallet with unCoinJoined UTXOs

...does this present a privacy risk?

Privacy concerns can be boiled down to the following questions: what information am I giving up by engaging in this transaction? And who am I sacrificing this information to?

When you engage with some counterparty to make a payment, they will gain knowledge about your involvement in the bitcoin transaction that includes said payment. An unrelated third party can also watch over all transactions, but they will not necessarily know that you are involved in said transaction specifically. By following the history of transactions and using some (imperfect) heuristics, a third party can potentially trace your coins through time, and given information about your involvement in some prior transaction, they can thus potentially link future transactions to you as well.

A coinjoin helps to sever the ability of any party to trace your coins through time (thus providing privacy). It does this by breaking the heuristics used to track a coin’s history, by effectively creating many possible histories for each output. With enough possible histories, it becomes ineffective to attempt to track a coin’s history through time.

So to answer your question more directly, let’s assume that you spend a coinjoined UTXO to some other wallet you control, and then eventually that UTXO is combined with a non-coinjoined UTXO in order to make a payment to some counterparty.

The counterparty you are engaging with could assume that you most likely control all inputs to the transaction (this is one of the mentioned heuristics), so they will now potentially have knowledge of: your use of coinjoin transactions, and your involvement in a specific coinjoin transaction. Additionally, they will have knowledge of your involvement in the transaction that created the other UTXO you spent. The counterparty could trace this other UTXO back through time, and probabilistically (using the heuristics mentioned) unveil some amount of your financial history.

For an unrelated third party, the same sort of analysis is possible, but they may not be privy to the fact of your involvement in said transactions. They may just be able to determine (probabilistically) that some group of transactions surrounding the transaction in question likely belong to a single user/wallet.

Example: the privacy granted by coinjoin transactions can be truly broken when a third party gains knowledge of your involvement with a transaction on both sides of a coinjoin. For example, if you bought coins from a KYC’d exchange, transferred them to an external wallet, coinjoined, and then sent the coinjoin UTXO straight back to the exchange (to the same user account), then your use of a coinjoin would be useless in protecting your privacy against the exchange. Further, the anonymity set for each other participant in the coinjoin would now be reduced slightly, since the link between least one input and output in the transaction would be known.

———————

So, coinjoin transactions can be effective if used properly, and the more they are used, the more effective they become. But they are not a silver bullet against privacy snoops! Improper use can completely destroy the privacy gains, and so a user must practice careful coin control in order to maintain their privacy most effectively. In the example above, if the user never combined the coinjoin UTXO with any other UTXO that is traceable back to them, then the coinjoin would be quite effective in preserving their privacy. But by combining it with unjoined UTXOs, some privacy may be sacrificed.


Bitcoinj How to create multi-signature address using bitcoinj

ECKey keyA = <something>
ECKey keyB = <something>
ECKey keyC = <something>

Transaction aTransaction = new Transaction(params);
List<ECKey> keyList = ImmutableList.of(keyA, keyB, keyC);

Script script = ScriptBuilder.createMultiSigOutputScript(2, keyList); //2 of 3 multisig
Coin value = Coin.valueOf(0,10); // 0.1 btc
aTransaction.addOutput(value, script);
Wallet.SendRequest request = Wallet.SendRequest.forTx(aTransaction.addOutput);
wallet.completeTx(request); // fill in coins

See mikes documentation