Would a Schnorr PubKey be a different length than a Taproot PubKey like P2WPKH and P2WSH?

A P2WPKH PubKey is shorter than a P2WSH PubKey.

No, not quite. A P2WPKH address is shorter than a P2WSH address. The addresses are both based on a hash of the underlying witness program (i.e. the locking conditions of the output). In the case of Pay to Witness Public Key Hash (P2WPKH) the witness program contains only the public key. On the other hand, Pay to Witness Script Hash (P2WSH) doesn't have a public key, its witness program consists of a witness script. P2WPKH and P2WSH addresses differ in length, because the hash for P2WPKH is a RIPEMD-160 hash which produces a digest of 20 byte (160 bit), while the hash for P2WSH is a SHA-256d hash which produces a 32 byte (256 bit) digest. Thus, the address for P2WSH simply has to encode 12 bytes more data and is that much longer.
Regarding Taproot and Schnorr, the outputs are actually indistinguishable, either commits the funds to a public key. In fact, if the spender doesn't make use of a script path (one of the scripts in a leaf of the tree), but spends the output using the key path, they remain indistinguishable even at spending time.
So, all segwit v1 outputs are always the same length, while the inputs may differ in size depending on how they got spent. They aren't categorized as two different output types, they are all categorized as Pay to Taproot (P2TR). Since the encoding used for public keys in P2TR is also 32 bytes, P2TR outputs end up being the same length as P2WSH outputs: 43 bytes.


Computers running the Bitcoin software pass transactions from one to the other to rapidly distribute new transactions throughout the network. Miners accumulate transactions from the network to put into blocks that they mine.

If you go to blockchain.info you can see new unconfirmed transactions scroll by on the bottom left.


Is it possible for two nodes to view blockchains differently?

Absolutely! This is why consensus is so important in Bitcoin. If there is a fork in the chain, a transaction could have 1 confirmation on one fork, and 3 on the other fork. Eventually one of these forks is going to win out and become the defacto blockchain. I don't think 3-4 confirmations would be common in Bitcoin, but if you are on an altcoin it definitely seems feasible. Testnet3, bitcoin's test network, routinely has these competing chains for short amounts of time -- after there is a clear winner the losing chain reorganizes on to the longest chain.


Is the Antminer S5 still worth it for low profit?

Your question doesn't make much sense, you are asking if it is profitable yet you acknowledge that you will be losing 60 cent per day due to electricity costs.

Bitcoin mining is not very profitable unless you have zero or low electricity costs, and the constant increase in difficulty makes your hardware obsolete. It is more worthwhile to invest in a concurrency simply, and wait for the value to rise (if it does)

Is the Ant miner worth it?
Well, if you are going to lose 60 cents per day, it most likely is not, and as difficulty increases you will make less and less while losing more.

Anyways, it seems more like you want daily income at the expense of your parents (weather they realize the more expensive electric bill or not). It probably is not worth it.


What example Bitcoin block has a Namecoin hash in it?

It won't exist. Merged mining only shows up in the auxiliary blockchain (Namecoin), not the parent blockchain (Bitcoin).

Basically, if you find a hash smaller than the target for both, then you submit the block to the Bitcoin network as usual and the Namecoin network as well. If you find a hash smaller than the Namecoin target but larger than the Bitcoin target, then you submit to Namecoin only. Basically the Namecoin blockchain gets stuffed with some junk from the Bitcoin blockchain.


Will mining in the (far) future produce a payout?

Miners earning = block reward + fees

Miners will continue to get block reward in the next hundred years, but long before the reward "stops", the miners will get most of their earnings from transaction fees, so they will continue to have economic incentive to mine, when the block reward stops.


Does ASICBOOST only work on Bitmain miners and how does one enable it on these systems?

"Our ASIC chips, like those of some other manufacturers, have a circuit design that supports ASICBOOST." - Bitmain statement

Bitmain claims that it wasn't used on mainnet. It is currently unknown how to make use of the feature. Likely, you'd need custom firmware and software.

Edit: Here's someone on reddit describing how to activate ASICBOOST: https://www.reddit.com/r/Bitcoin/comments/63yo27/some_circumstantial_evidence_supporting_the_claim/dfy5o65/


Do I need to wait for blockchain to complete to use private key elsewhere?

You can export your private keys (using the dumpprivkey command in the console) without having to wait to sync the blockchain.


How does a node compare two blockchains?

Block headers include a field called bits, which can be used to calculate the difficulty and hence the amount of proof-of-work in the chain. There's probably a shortcut to being able to eliminate a 100,000 longer chain, but all core does is calculate the proof-of-work present in both chains and take the one with more.

Note that block headers are only 80 bytes each, so the 500k blocks would only be about 40 MB, not an unreasonable amount of data to calculate how much proof-of-work a chain has.


how do i convert bc1 address to hex? for coinbase transaction

BIP173 specifies the conversion from Bech32 segwit addresses to scriptPubKey. You probably want to use some reference software to do the decoding (there are several links in the BIP). If you need the details, it is approximately:

Split the address in a "human readable part" and a "data part"; the last '1' character in the address separates the two.
Convert the data part from characters to symbols (integers in range 0-31) using the character map in the BIP.
Verify the checksum (last 6 characters of the data part). I'll refer to the BIP for the details.
Interpret the symbols of the data part as follows:

One symbol: Witness version (number 0-16)
Variable number of symbol: witness program
The last 6 symbols: the checksum

Perform various sanity checks on the data sizes and ranges, also illustrated in the BIP.

The retrieved information (witness version and program) can the be converted to a scriptPubKey, as specified in BIP141. Namely, OP_n (where n is the witness version), followed by a push of the witness program. Note that OP_0 is 0x00, while OP_1-OP_16 are 0x51..0x60.
There is a proposed amendment called BIP350 which improves the checksum for witness versions higher than 0 (which are currently not in use, but may become in use following the activation of Taproot (BIP340-342).
This is how conversion from addresses to scriptPubKeys works for all transaction outputs, FWIW. It is entirely unrelated to coinbases.
Disclaimer: I'm a co-author of all the BIPs mentioned in this answer.


Just run ./bitcoind -reindex and this will fix your problem.

-rescan is for missing wallet transactions


Talking to bitcoind thru web browser returns empty JSON document

You need to POST the request according to the JSON RPC specifications. So this will not work using Firefox without any special extension that lets you set POST information. You cannot simply request the page http://user:password@localhost:8332/getinfo and expect bitcoind to return the getinfo. There is no page system, it's not a normal www-server (i.e. pages hyperlinked together), it just uses the HTTP protocol to transport JSON. As long as you make that POST request correctly, I don't think it mattes what page you call.


What is the meaning of difficulty in Bitcoin mining?

Suppose I give you some very complicated function f(), and I assign you the task of finding an input n with the property that f(n) is small.  That can be difficult.  I can make it more difficult by changing the definition of "small".  If I ask you to find an n such that f(n)< 100, that's difficult.  If I ask you to find an n such that f(n)< 90, that's more difficult.
Once you've compiled a block, you're confronted with a function f().  The function itself depends both on the block you've just compiled and the solution someone found for the problem associated with the preceding block.  Successfully mining the block means finding an n such that f(n) is small.  The only way that anybody knows to solve this problem is by trial and error.
The definition of "small" is periodically adjusted.  That definition of "small" is what people mean by "difficulty".


In order to verify signatures, you need to feed btcdeb the two transactions (the relevant input transaction and the transaction spending the input) for it to be able to calculate the signature hash.

Edit: as of January 18 2020, you can now feed it the signature and pubkey as a pair instead. You can also replace the signature and pubkey in the script with mock values (e.g. "mysig" and "mypubkey").

See https://github.com/kallewoof/btcdeb/blob/master/doc/mock-values.md


What is P2PK, P2PKH, P2SH, P2WPKH - ELI5

P2PKH: "Pay To Public Key Hash"

This is how transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key and through some cryptographic functions will check if it matches with the public key hash, if it does, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security.

P2PK: "Pay To Public Key"

This is similar to P2PKH; the difference is that it does not conceal your public key. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details.

P2SH: "Pay To Script Hash"

The outputs of a transaction are just scripts that, if are executed with specific parameters, will result in a boolean of true or false. If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.

This can also be used for puzzles like this one.

P2WPKH: "Pay To Witness Public Key Hash"

This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction validity, there is a new part of the transaction called witness where the validity occurs.

  Also what is the difference between BTC held in P2SH and Unspent P2SH Output here?

This means that out of all the P2SH transactions (transactions that can be spent by anyone with a set of parameters [scriptSig] that results in the execution of scriptPubkey with true), the ones with unspent outputs have not been redeemed.

I recommend this video by Andreas Antonopoulos on Bitcoin scripting.


Can I force my company to pay me in Bitcoin

Probably not - I mean you're not in an absolute position to demand them to compensate you via bitcoin.  Can you possibly get an E-checking account with someone like INGDirect then have your BTC automatically dispursed via bitwage or even lawnmower...I think you could even do an auto-rebuy with coinbase if you felt inclined to do so.


Why is the bytestring 0xaa21a9ed used as the witness commitment header in SegWit?

It's random.

The intent was choosing something long enough to avoid having someone accidentally create an output that matches, but short enough that it doesn't unnecessarily makes SegWit blocks larger.


Targetting a specific wallet when sending commands using RPC commands to bitcoind

When more than one wallet is available, the wallet is selected by sending the RPC requests to <host:port>/wallet/<wallet_name>.

You might have to play around with the exact form, I suspect it might be <host:port>/wallet/wallets/walletA in your case, or <host:port>/wallets/walletA, or <host:port>/wallet/walletA.


How much does system RAM matter for Litecoin mining?

i have 3 7950s with 3gb of ram each and only 2gb in the machine, it would work even with 1 gb i think

there was a bug with an older version of openCL or cgminer (cant remember) that did use pc ram instead of gpu.


What are the factors that drive the cost of bitcoin mining?

The main factors making mining attractive are :

The coin's value
The mining difficulty
The price of electricity
The price of the required hardware
The mining fees

The higher the coin's value the higher the miner is rewarded. The less difficult it is, will likely result in more coins. Some countries have almost free electricity which makes mining much cheaper. There's also the initial investment, which is the required hardware for mining. Mining fees also help increase mining's profitability.

When mining a coin becomes attractive more miners will come which would result in more CPU power which gets corrected by a higher difficulty. If suddenly half the mining power was to disappear, we would see a difficulty adjustment.


Is there a namecoin (or similar) social network? How would it work?

Well Retroshare somewhat falls into this category. It is not Coin-Based however, rather related to Bittorrent DHT technology und not well documented.

There is also the Bitmessage protocol which uses Coin technology for exchanging mail.

I do not know why you would build such a system as a Coin network, plain BT style DHT is more suitable for this purpose in my opinion. I do not know any good reason why Bitmessage does it this way either. I think it is just overcomplicated and not well thought through. The usecase is just very different from Bitcoin.

I mean, what would be the purpose of the block chain? Prevent double friending?


How can I import my public key from a mnemonic seed phrase to receive a payment?

The idea behind a seed mnemonic phrase is to provide a readable format for the seed. It is mostly used for backup purposes. Let's say you lost your phone. You'll be able to recover your bitcoin wallet based on the word list you have saved in a secure place. Also the Trust Wallet may stop being available as an app at some point, and the seed will allow you to restore the backup in another software wallet if you know your derivation paths.

How do I use the words to get the key (public or private) for
receiving bitcoins?

First of all, you don't need the private key to receive bitcoin. If someone asks you for your seed or private key - be aware it is probably a scam. There are ways of using the seed to set up a watch-only wallet - based on xpub derivation which Trust Wallet doesn't provide (it's an extremely basic bitcoin wallet).
But you'll see your bitcoin address when clicking on the bitcoin logo in the Trust Wallet app and then going into the "receive" tab. Trust Wallet will create a set of keys automatically based on the seed and will show you just the one address for deposit.


Multiple pool options in Antminer S9 Settings

The AntMiner S9 manual is available at https://shop.bitmain.com/files/download/AntMiner%20S9%20Installation%20Guide.pdf

The manual says:

  The AntMiner S9 can be set up with three mining pools, with decreasing
  priority from the first pool (pool 1) to the third pool (pool 3).

  The pools with low priority will only be used if all higher priority
  pools are offline.

On older S-series models there used to be a "Pool Balance" setting on the pool screen, below the "pool 1", "pool 2", "pool 3" in your screenshot. From the manual for the old S3:

  AntMiner can set up three mine pools, the priority decreases from
  first pool (pool 1) to third pool (pool 3). There are three Pool
  Balance option:

  Failover: Automatic backup when Miner faults;
  ‘Failover’ is by default. The low priority pool will start to work,
  only when the high priority pool encounter fault.

  Balance: Change
  multipool strategy from failover to even share balance.

  Load Balance:
  Change multipool strategy from failover to quota based balance.

I do not know why this feature was removed in later models.


The default port for bitcoin regtest is 18444. You can set a custom port with port=<port> in your bitcoin.conf or by passing -port=<port> as argument.


How to get balance by any address using rpc bitcoind?

You would run the listunspent response through a loop and total up all the values from all the unspent outputs for that address.


When the last Bitcoin block is mined, how would transactions continue?

A misunderstanding. I do not know what leads you to believe that there will be a last block.

It is true that block rewards have a halving period and will eventually, in many years, reach zero, but, the transaction fees are also paid to the miner so mining will continue.


What is the status of the "Hong Kong Agreement"

The full code for Segregated Witness was released on 19th of April, which to the letter fulfills the requirement. However, apparently some people had understood the first point to mean that it would be in production in April which was not the case.

Following the above, an implementation for a hard-fork would be expected to be delivered by 19th of July.

IIRC, Bitmain's Jihan Wu has recently stated that point 4 is to be interpreted as them requiring the code for a blocksize increase hardfork to have been merged into Bitcoin Core before they run Segregated Witness in production. This is of course a much stronger requirement than point 2 and point 4 which could be read as them starting to use SegWit at the latest when code for a hardfork is released.

The argument has also been made that by allowing voting for Classic, some pools have breached point five. The disagreement here is chiefly about whether Classic constitutes an incompatible version. Until a Classic node activates, it follows the same rules, so proponents argue it is compatible. Yet, since Classic breaks with the current rules as soon as it activates, others declare it to be not "Bitcoin Core-compatible".

Altogether, it seems to me that there are still a lot of misunderstandings and conflicts of interest to be ironed out. Vastly diverging priorities and language barriers add to the difficulties. There also seem to be very different assumptions about where the community support lies and how the power dynamics in Bitcoin will work out.

As far as I can tell, we can only wait and see how the situation develops. The next step appears to be the imminent inclusion of Segregated Witness into the next Bitcoin Core release candidate. Once some miners start signaling readiness for Segregated Witness, the situation will probably evolve quickly.


Why would more confirmations help in a 51% attack scenario?

If the exchange waits for 6 confirmations (1 hour) and sends the dollars then, it could be possible that no one even noticed that there was such an attack. Then a scammer could pay out twice.

But if the exchange waits 12 hours for example, some miners will probably recongnize that they do mine on a shorter chain within this time.

In the bitcoin system, 6 confirmations mean in more than 99.9% of the cases that the transaction is done. There are only a few scenarios in the bitcoin history when that was not the case.

But you need less mining power to attack Bitcoin Gold. So I would aggree that the exchanges should wait longer.


How Extracting address Bitcoin to script multi signature

The correct address is 3CD1QW6fjgTwKq3Pj97nty28WZAVkziNom. The individual public keys are only able to access the coins if they act together in a group of at least 2 out of 3. If you derive a regular p2pkh from each individual key, you will end up searching for utxos that likely don't exist.

Also note that each individual public key does not necessarily mean that there are that many individual people involved. Many security conscious companies and people have multisig addresses with each key stored on a separate device/location, requiring multiple signatures from different systems, etc. They may all still be under the control of a single entity.

When cataloging transactions and matching patterns across the network, you should be working with the P2SH address for a multisig address. Breaking it down into its components will produce incorrect results.


To put it simply, it depends on the value of the transaction. There's little incentive for someone to try ripping you off with a low value transaction, but there is a strong incentive to do so with a high value one.

This has been raised before, but the answer that I found easiest to understand is quite old: https://bitcoin.stackexchange.com/a/832/516

Note that waiting for 1 confirmation isn't a wait of "at least 10 minutes", as half the time it will be faster than 10 minutes. For high value transactions more confirmations may be prudent.

There is good info here too: https://en.bitcoin.it/wiki/Confirmation


Can bitcoin system be modded to work without internet

It depends on what you mean by "work without the internet".

There is already at least one vendor who is making physical bitcoins. That is accomplished by exposing the public key on the face of the coin and hiding the private key under a tamper proof sticker. Such a scheme still relies on the internet, however, because the value of the coins is dependent upon the internet based Bitcoin blockchain.

The actual Bitcoin protocol itself could not be modified to exist without the Internet (or some equivalent wide area network). This is because to prevent the double spend problem without a central authority you must have communication between the network to determine if a coin has already been spent. (The physical coins above essentially rely on trusting the "central authority" of the coin maker. For example, that he will not mint duplicate coins, mint coins without valid private keys, and that his tamper proof stickers are truly tamper proof.)


I imagine different faucets have different business models. The ones I've seen either show you ads, or make you solve captchas (which has potential value to spammers, etc).


What are the differences in these methods of creating wallets offline?

The problem with using an operating system like Windows to create these password-protected wallet is that you could still be offline (not connected to the internet), but if you have some sort of virus installed, they could copy your wallet, get your password that you'd type in, and store it locally. Then as soon as you connect it to the internet, they would send all this info to their servers and you're wallets would now be breached.

So using an operating system that is secure and open-source is very important. I would personally even disregard Ubuntu, because it has a graphical interface and it comes preinstalled with lots of questionable software - some of which has been recently set to send unwanted data to their servers.

Using something like FreeBSD or other Linux distros, directly using the command-line, and no graphical interface, would lower the barrier for any sort of attack.


You, the miner, are the one being paid by the pool operator for doing some computation. It's a free and open market. You can switch pools if you're unhappy with the reward or the honesty of an operator.

To become a pool operator there's no election process or formal checking whatsoever. Again, it's a game based on reputation. Just like any other business, if an operator misbehaves (by stealing funds or something), they lose reputation and therefore users.


Why not decrease the difficulty to increase capacity?

One problem is that lower block times mean an increased chance of forking, which makes head of the chain, and the system, less reliable.

Another problem is that it normally takes a block a few seconds to a minute to propagate across the network. Proportionally that time becomes a lot higher with a decreased block time, giving the original miner and miners with direct connections to them a more significant lead time.

Finally, it throws off the whole schedule of when Bitcoin will be released. New Bitcoins are set to be mined past the year 2100, that would be significantly sped up, changing a lot of existing assumptions about inflation and economic assumptions about scarcity of the currency. Since the change would have to be a hard fork it would be controversial both economically and technically.


How does changing transaction data in a block change the hash of previous block?

It does not!

Next block contains a reference to previous block header hash.

Let's say the blocks are ordered as 1<-2<-3<-4<-5<- with block 1 being the first block in the chain (so called genesis block).

Block 2 header contains a reference to block 1 header hash.

Block 3 header contains a reference to block 2 header hash.

Block 4 header contains a reference to block 3 header hash, and so on.

If someone changes block 3 header block 4 will not point to that block's header any more, and the part of the chain -4<-5<-6<-... will be invalid.

Each block's header contains a construct (called Merkle root) which is derived from all transactions. Thus changing a transaction in block 3 will make Merkle root in the header of block 3 invalid and the attacker must also change that. Meaning the header will change and thus block 3 header's hash will change. Thus block 4 header won't point to block 3 header hash any more.

NOTE: On the other hand block 3 will also be invalid with respect to its required target threshold but this is another issue.


How do 'Sphinx' invoice-less payments on the Lightning Network work?

Usually a merchant will generate a (psuedo)random 32-byte value and hash it. This becomes the payment_hash which identifies the payment in the network and is transferred to the purchaser in an invoice. When the user makes the payment, they send this payment_hash with an onion packet, as a conditional payment which will complete if the preimage of the hash is provided. Each hop will forward this payment hash, until the destination must reveal its preimage to the penultimate hop in order to complete the transfer of funds. The hops will then transfer the preimage backwards through the route until it reaches the purchaser, and serves as proof that the payment suceeded, under the assumption that nobody other than the merchant could know the preimage. This prevents reuse of a payment_hash because an intermediate hop may have knowledge of a preimage which has been used already.

The HTLCs are exactly the same with spontanious payments, the difference is that the purchaser creates the payment preimage and payment_hash. The payment_hash is transferred as usual, but the preimage is encrypted inside the onion routed packet in a way that only the merchant can decrypt it.

The onion packet has 12 bytes of padding at each hop which can be utilized to send additional data, but also, the onion packet can have "virtual hops" after the destination hop of the payment, which the merchant can decrypt. These virtual hops can contain 32 bytes of data because the usual amount, SCID and cltv fields can be repurposed to hold additional data, since you're not forwarding any payment beyond the destination. A couple of bytes are used as flags to indicate the type of data, and the aggregation of the extra data in the virtual hops is known as the Extra Onion Blob (EOB).

The entire onion packet remains the same size, so the amount of additional data which can be transferred with the payment is still limited, with the more hops required for actual payment, the fewer virtual hops. A spontanious payment requires at least 2 virtual hops because there are flags and a 32 byte primage to encode into the EOB.


What prevents a miner to be ignored by the other participants?

Bitcoin miners are anonymous. There’s no identifying information in blocks that could be used to censor a particular participant. The attributions for miners shown on block explorers are guesswork presented as fact.


What exactly does censorship resistance mean?

This is a very overarching topic with many answers covering many facets of the Bitcoin / blockchain infrastructure. The network-level is considered by multiple communities to be the enforcer of censorship as it pertains to digital content and transactions.

In Bitcoin we would need to examine the network level and how enforcement of network decisions are made. First code changes are committed and either denied or merged to the actual code base. It is then up to the mining community to upgrade to that newer software version. The network upgrades to new changes when the majority of miners are running that new version.

If the overwhelming majority of mining is consolidated by one actor, or a nation-state, they could effectively censor your transactions by imposing limiting factors on your wallet.

This is only a major issues in Bitcoin and Bitcoin-derived currencies because of the public nature of transactions.


How does consensus protect from lying about transactions?

You can think of a bitcoin address like a machine that produces locks and a bitcoin wallet like a machine that produces unforgeable, labeled keys.

Say Alice received 1 bitcoin from Bob and wants to send it to Charlie. If Alice has 1 bitcoin to send, that means there is 1 bitcoin that is locked with a lock from her lock-making machine.

When Alice wants to send that 1 bitcoin to Charlie, she must have his address. She uses his address as a lock-making machine and makes a lock that only Charlie can unlock. She feeds this to her key-making machine and makes a key to the lock that only she can make a key to but labels it with the lock she got from Charlie's lock making machine.

This new key only opens the 1 bitcoin Alice will send to Charlie, and only Alice could make it. The attached new lock can only be opened by Charlie, since only he has the matching key-making machine.

You consider someone to have "sent you a bitcoin" if they locked it with a lock that only you can open.

So, a block that contains invalid transactions is itself invalid and ignored. You can only form valid transactions that transfer bitcoins with the appropriate keys or the transactions are invalid.

This might make you wonder what you need consensus for at all. And the problem is that Alice could maliciously make multiple keys that open the same lock, transferring the same 1 bitcoin to both Charlie and Dave. We need consensus to agree which of a set of conflicting transaction, each individually valid, we can rely on.


Bitcoind suspend when Synchronizing blocks

The new version (0.10 / RC1) has a rewritten block-download mechanism which significantly improves synchronization which could result in less similar issues.

A workaround for the current version is to deploy the -maxconnections=<n> option and set it to a low number to reduce parallelism and thus receive less orphans in total. Set -maxconnections=1 to receive little to no orphans (essentially only for the newly announced blocks).

You can also use the -maxorphanblocks=<n> option (which has a default value of 750), try decreasing it and the daemon will probably bypass the stall point, as keeping less max orphans will prevent your system from running out of resources (eg RAM), which I suppose is what currently happens.

Another workaround is to just download the bootstrap.dat torrent if you are still many weeks behind the current block.


What can a pool operator do with their miners' hashpower?

Commit double-spends, either themselves or for hire. If the transactions reversed are accepted with 0 confirmations, they don't need a very high hashrate to do this with some effectiveness.
DoS attack on Bitcoin, by including no transactions in blocks and rejecting all other blocks. This requires ~50% to be done effectively.
Similar attacks on alternative blockchain-based currencies, which is easier since they are usually smaller.
Merged mining - not nefarious in itself, but should be done only at the agreement of miners.
Coin mixing - paying generated coins to people in need of fresh coins, receiving from them independent funds to be paid to miners. (Illegal if done for the purpose of money laundering)
Include too few transactions, making it harder for people to have their transaction accepted.
Include too many transactions in a possible future scenario where a transaction fee equilibrium is obtained by a gentleman's agreement not to include transactions too cheaply.
Things unrelated to Bitcoin, such as password cracking (generally possible only with custom mining software).


A brute force hack would not work. Image a computer capable of expelling the lowest amount of energy conceivable to record a change in a bit from 1-0 or 0-1. Now take this computer and make it on the scale of our sun. Also imagine we can cool this computer to near zero kelvin with no other energy input. All input energy goes into changing bits and that's it.

Now take all the power our sun will make in its lifetime, and power the computer with it. It will take longer than imaginable to even just simple count to 2^256 let alone try to brute force attack a sha-256 algorithm. So brute force will never work.

--

You must gain more computing power than 50% of the network. This means on average you will create more block solvers than the <50%.

But wait again you need to account for the blockchain to date, so once you get this computer power you must now create a new fake blockchain which will take time; (Currently it take 8 hours to download the full chain, imagine how long it would take to compute it!) your new blockchain must be made (this is the whole point of the attack change the blockchain so you have more btc).

So assuming you have time to create this new blockchain, no everyone must accept it. It is in the bitcoin protocol to accept the longest blockchain to date, because it has the most transactions the most knowledge of the entire system.

So you create this blockchain and send it to everyone, they all then proceed to take their 8 hours to get the new blockchain, but wait.... why is there a new blockchain everyone would say!?

It would be obvious someone has made a new one because you are downloading it as if this is the first time on the network. And the real smart people who write bitcoin protocol would be very privy to this, and at the least have 8 hours to react. It would be to obvious.

--

The only real way I think to hurt bitcoin is to buy up all the coins, or release a whole bunch of coins into circulation greatly affecting prices.

But this would even be sorted out by the bitcoin design.

The price drops, people stop mining because it become less profitable. Cause the miners stop difficulty goes down, more people mine because it is profitable because the difficulty is so easy they can make enough btc to cover their costs, bitcoin is up and running again.


What does it mean for a transaction to be over spent?

As you mentioned, the sum of the value of spent coins (inputs) should be superior or equal to the sum of the value of the created coins (outputs) ; the difference being the miner fee.

This condition is checked by every peer of the P2P network when relaying transactions and blocks containing transactions not respecting that condition will be rejected as part of the consensus rules.

It is therefore not possible to "overspend" by creating more money than what you have ; but there's been one notorious bug where this was proven wrong: the value overflow incident.


Account change address is not showing up with `getaddressesbyaccount`

Call listreceivedbyaddress(0, true) to get all of your addresses (even the empty ones or those who have a zero-confirmations balance).

By default (parameterless) it will only list the addresses that contain some confirmed balance and those who have at least one confirmation for their unconfirmed balance.


How easily can asics be ported over to other sha algorithms?

Application Specific Integrated Circuits are hard set to only do one thing, and in the case of bitcoin ASICs, that's SHA256 hashes. You cannot re-write the software, you would need a new circuit built that only does SHA1 or whichever hash you're looking for.

https://en.wikipedia.org/wiki/Application-specific_integrated_circuit


is there any daemon available for bitcoin cash (eg-bitcoind for bitcoin)?

You can use Bitcoin ABC. But be careful because it is a fork of Bitcoin Core and uses most of the same code, including also naming its daemon bitcoind, so you should not install it on the same machine as Bitcoin Core.


How long would it take to break a 32 bit key / encryption

Way too fast.
It's only 4,294,967,296 combinations for 32 bit and 65,536 for a 16 bit. I assume it can be cracked in seconds/minutes by a high-grade consumer laptop.
The resources required for a brute-force attack grow exponentially with increasing key size, not linearly.
I would also suggest reading the article about breaking mnemonic seed where author had to calculate SHA-256, SHA-512, RIPEMD-160, EC Addition, EC Multiplication in every iteration and he was able to check ~143,000 mnemonics per second.


parsing bitcoin input and output addresses from scripts

the output address is derived solely from the output script starting from step 4 in the wiki like so:

first add leading zeros:

0012ab8dc588ca9d5787dde7eb29569da63c3a238c

then hash with sha256 (if you look in the wiki this is actually part of the OP_HASH160 operation) to give:

e158c4be10913422dadcf1c36843020ebb3ffe9d0cb13fb9e8c0a564a53c7832

then hashed with sha256 again (the wiki is wrong here - it says to use ripemd160, but actually sha256 is required again) to give:

96bf1d277213bbcd91145138e4c7ad8dcd6e1de1c39884fcbc1f5a6d4d7aee93

then grab the first 4 bytes of this result (96bf1d27) and stick them on the end of the original hash160 public key with leading zeros:

0012ab8dc588ca9d5787dde7eb29569da63c3a238c96bf1d27

convert to decimal:

457790304922245030616719694560989441716273193824169172263

base58 encode to give:

2higDjoCCNXSA95xZMWUdPvXNmkAduhWv

and stick a 1 in front of it all to get the bitcoin output address:

12higDjoCCNXSA95xZMWUdPvXNmkAduhWv

now to figure out how to get the input addresses...

thanks to this answer, we can see that both the signatures are der encoded in the following format:

0x30: a header byte indicating a compound structure
a 1-byte length descriptor for all what follows
0x02: a header byte indicating an integer
a 1-byte length descriptor for the r value
the r coordinate, as a big-endian integer
0x02: a header byte indicating an integer
a 1-byte length descriptor for the s value
the s coordinate, as a big-endian integer
a hashtype byte

so, decoding the raw script signatures:

493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

0x49 = OP_PUSHDATA0 - push 73 bytes onto the stack (script command not part of the signature value)
0x30 = header byte
0x46 = length descriptor (70 bytes)
0x02 = header byte
0x21 = r value length descriptor (33 bytes)
00e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b the r coordinate as a big endian integer
0x02 = header byte
0x21 = s value length descriptor (33 bytes)
00b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d the s coordinate as a big endian integer
0x01 = hashtype byte

and the second raw signature has the same format too:

493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01

0x49 = OP_PUSHDATA0 - push 73 bytes onto the stack (script command not part of the signature value)
0x30 = header byte
0x46 = length descriptor (70 bytes)
0x02 = header byte
0x21 = r value length descriptor (33 bytes)
00a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3 the r coordinate as a big endian integer
0x02 = header byte
0x21 = s value length descriptor (33 bytes)
00911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf the s coordinate as a big endian integer
0x01 = hashtype byte

so this confirms that the signature values in the transaction inputs actually do not contain public keys at all. the input addresses actually come from the previous transaction outputs which can be identified through the input hash and input index in the current tx.


1) Your command line looks fine. Remember that %s will be replaced by a transaction id, such as 9de5056696618f22237eb280bbefe94c1d19661de960a1f2c546a0e3a2bc4600.  So if you can run the script at the command line like this you should be ok:

C:\Python27\python.exe D:\LiVe\listener.py 9de5056696618f22237eb280bbefe94c1d19661de960a1f2c546a0e3a2bc4600

2) The transaction id by itself does not contain the number of confirmations.  To get the number of confirmations, you'll have to look up the transaction yourself.  You can either use an external service like blockchain.info's API, or call bitcoind's GetTransaction.

WalletNotify will fire twice for each transaction: the first time that the transaction appears on the network and the first time that a block is published that contains that transaction.  There are no notifications on subsequent confirmations.

3) If you want to move coins between accounts within a wallet, you can use the move command.  But if you are going to publish the transaction in the blockchain (i.e. send from one address to another, even within the same wallet) then you may have to add a transaction fee, depending on your inputs.


can someone help me start my node please

Try running the command 'bitcoin-qt' in your terminal.


Why so many transaction send bitcoins to the sender?

An output of a previous transaction can only be spent wholly. So if you have 3BTC and want to send 0.5 to someone, you make a transaction that sends the 0.5 and then 2.5 back to your own address. This is called "change", just like you get change when paying in the supermarket, except in this case you give the change to yourself so you don't need to worry about the other person running of with it.

Note that this change address is supposed to be a brand new address (owned by yourself) and NOT the same address. Address re-use is bad for privacy: as you've just discovered you can in those transactions easily determine which part of the transaction was change and which was actually sent to some other person.


Can more bitcoins be transferred to a paper wallet address once it is created?

Yes, you can.

The wallet itself does not hold any money. It is just a private key, to which the coins will be associated.


You should be fine as long as you avoid sending coins specifically to that address, but I would delete it just to be safe. The app that I use doesn't let me delete addresses directly, so I just re-installed it.


You still have to include some PoW for every transaction you submit and verify 2 older transactions this way. So everybody is sort of a small miner.


How can Bitcoins be sent without Blockchain.info knowing your private key?

The private key is needed only to sign the transaction, to authorize it to spend your coins. This is done on the client side. The signed transaction is sent back to the server, which will take care of transmitting it on the Bitcoin network.

A defining feature of public-key cryptography is that it is not feasible to deduce your private key from the signature.


Is it possible to set up an Antminer S3 using a a Raspberry Pi?

An Antminer S3 operates as a stand alone computer, so you need no controller. The device is configured and managed through a web browser interface, so you can configure it from any web browser.

The only downloaded tool from Bitmain for the Antimer that runs on a PC is their "IP address finder" app, and you can use any of hundreds of apps to discover the IP address of devices on your LAN, including Fing.


You can code a trade engine in language like C++ or any other which ever is suitable for you. What actually happens in the back-end is an script keeps on repeating after particular interval for new trades or deposits that script can be coded in any language which can communicate with the database. Following is the example of a PHP script which checks for new trades and then update the database if any new trade took place:

<?
$sell = mysql_query("SELECT * FROM trades WHERE `From`<>`Type` LIMIT 1000000000000");
$num = mysql_num_rows($sell);
echo $num;
for ($i = 0; $i < $num; $i++) {
$id = mysql_result($sell,$i,"Id");
if($id != 0)
{
    $trade = new Trade($id);
    $trade->GetEquivalentTrade();
    $trade->ExecuteTrade();
}
}
?>


Yes, absolutely. Here's just one example of how this can happen:

You invest Bitcoins worth $100 in some kind of high interest scheme.
You cash out of the scheme and get Bitcoins worth $200.
You invest those Bitcoins.
You lose them.
The high interest scheme turns out to be a Ponzi scheme. You are sued to clawback the $100 value of the Bitcoins that were fraudulently paid to you.
You lose that suit and now owe $100 on top of the $100 you invested.

Another example would be if you unknowingly withdraw funds from an exchange that's insolvent, then reinvest and lose those funds. If the exchange declares bankruptcy, your withdrawal could be ruled a preferential transfer and you would have to repay it.


cgminer works just fine for BTC but LTC mining won't get temps over 50C

Here's the cgminer.conf for HD6770M I use:

"temp-cutoff" : "105",
"temp-target" : "65",
"intensity" : "13",
"vectors" : "1",
"worksize" : "256",
"kernel" : "scrypt",
"scrypt" : true,
"lookup-gap" : "2",
"thread-concurrency" : "3200",
"shaders" : "480",
"gpu-engine" : "815",
"gpu-fan" : "100",
"gpu-memclock" : "919",
"gpu-vddc" : "1.055",
"temp-overheat" : "100",
"gpu-threads" : "1",
"kernel-path" : "C:\\path\\where\\cgminer\\is" (double "\")

Hope that helps!


What is a workaround to fundrawtransaction for watchonly addresses

A bitcoin address, watchonly or not, represents a public key.  This public key has a corresponding private key.

If you import a watch only address the corresponding private key is not imported.  So you cannot spend any unspent outputs from those addresses.

If you want to send bitcoin to the watch only address, you have to make sure you know the corresponding private key or your bitcoin will be lost.

Choose an unspent output from another address where you know the private key.  Take this output when you run 'createrawtransaction'.  Sign the transaction with this private key then 'sendrawtransaction'.

Optionally before you 'sendrawtransaction', decode your hex string with 'decoderawtransaction' and make sure everything is correct.


Why the txn_count is zero in the block message?

I solved the problem, I was reading the Nonce from the block as a 64 bit integer like in the version message instead of a 32 bit integer.


Compiling litecoin on Macosx: llvm-g++ not found

For anyone who runs into this problem, the newest version of Xcode 5.0.2 and Oct 23 version of command line tools did not install the llvm-g++ file. I rolled back to Xcode 4.5 and installed the first mountain lion command line tool release and this fixed the problem.


Bitcoin core node is not starting after -prune is applied in bitcoin.config file

By pruning the blockchain you:

  Reduce storage requirements by enabling pruning (deleting) of old
         blocks. This allows the pruneblockchain RPC to be called to
         delete specific blocks, and enables automatic pruning of old
         blocks if a target size in MiB is provided. This mode is
         incompatible with -txindex and -rescan. Warning: Reverting this
         setting requires re-downloading the entire blockchain. (default:
         0 = disable pruning blocks, 1 = allow manual pruning via RPC,
  =550 = automatically prune block files to stay under the
         specified target size in MiB)

So, -txindex cannot be enabled when the blockchain in pruned


Blockchain.info API - Check transactions from one address to another

You can use pybitcointools history(address). Note that this function has bugs, so try my fork instead.

Or, the API request for 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX would be:

https://blockchain.info/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX?format=json&offset=0

If there's more than 50 results, you'd change offset=50.

I'll provide more details if required.

My personal recommendation would be to use this API call, as there's no offset issues:

https://bitcoin.toshi.io/api/v0/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX/transactions


why does my bitcoin wallet not access funds in my coinbase portfolio?

I tried Bitcoin wallet ...

There are many different Bitcoin wallets and the answer may depend on exactly which one you are using. For example there is "Bitcoin Wallet" for Android phones which is sometimes known as the Schildbach wallet. There is also Bitcoin Core for PCs and many others.

... but it only accesses the active Bitcoin, not the funds in my portfolio.

A typical Bitcoin wallet such as Bitcoin core or Electrum gives you exclusive personal control over some money. These are what is called non-custodial wallets - there is no third-party custodian who has custody of your money.
Coinbase accounts are custodial. So far as the Bitcoin network is concerned, Coinbase own money in coinbase accounts, not you.
Ownership of money in the Bitcoin network is determined by who holds the secret numbers known as private-keys. Money is associated with a private key. If a wallet doesn't have the private key for some money, then that wallet cannot access that money to spend it.
If it helps, imagine having bank accounts at two different banks. Your bank-statement from one bank won't include any money in the other bank. You cannot instruct one bank to send someone money that is in the other bank. Bitcoin doesn't work like banks but it does have separation of control where there are several private keys in use.

How do I recover the portfolio money?

You can, for example, get your non-custodial wallet to display an address to "receive bitcoin". Then log in to coinbase and use it's facilities to pay money to (or withdraw money to) that address.


Is the block size limit miners'-only thing, or should users participate?

Ultimately, the consensus rules are set by (the consensus of) those running full nodes, and not by miners. If all Bitcoin node operators decided to switch to different rules for whatever reason, miners have no choice but following, or see their blocks become worthless.

Because of that, in the extreme, miners have no say at all. They have to produce blocks that satisfy the rules that full nodes demand.

Of course, in practice, the hard part is how to get consensus among full nodes, and this is a public debate in which many parties participate: developers, users, and miners. All of them have an incentive to form a consensus, because the alternative may be an irreconcilable fork (with two independent currencies, where each coin that existed before the split can be spent once on each side - the exact problem that Bitcoin was designed to solve).

While a single user can't just demand a change (or non-change) of rules, a large collection of economically relevant nodes certainly can.


Where is the QR code listed in Electrum 3.0.3

I assume you are talking about the QR code for an address in your wallet. If you go to the receive tab, you will see a receiving address filled in the Received address text box. Next to that, there's a QR code. That QR code is for your address.


Let's suppose I have lost everything except this extended master key. How can I setup a new fresh computer and retrieve all my bitcoins just with this key?

According to How to get xpub or mpk(bip32) for my bitcoin core wallet?

  you can export the xpriv with dumpwallet

According to https://bitcointalk.org/index.php?topic=3866008.0

  Bitcoin Core does not have a way to directly import [master] private keys.
  You could derive a bunch of private keys in WIF from the xpriv and import them all at once, but you can't import the xprv directly.


There are legal differences. I won't go as far as saying I can tell you if any of them are advantages or disadvantages, because I don't think I can.

If both your exchange company and their banking is in your country, then there is no question if there is any legal obligation on your part to tell your government that you dared move money outside the country. Check your laws; if you're middle class, you'll be surprised how low the trigger amount for such issues that you might think would afflict only the seriously affluent can be.

One thing that is not very different is that no bitcoin exchange I am aware of is fully compliant with all laws fit for all sorts of similar enterprises for every location where they do business, and most probably are not compliant in any or only in hardly any. Some like to advertise their compliance, but I suppose the one case (campbx) where I did get more information on that by inquiring is typical. They wrote me earlier this year that they were then only compliant with the (comparatively easy) Federal FinCEN rules, not the rather tough state money transmitter licensing, although they emphasized their efforts towards progress on that front.

Whilst you may argue that this is mostly because many people don't get how these laws cannot possibly apply to bitcoin businesses, that hasn't stopped authorities in some countries from temporarily seizing a bank account of a bitcoin exchange (one case I know of was in Poland, and one not related to such laws in Germany) or even seizing a bank account for forfeiture (one case I know of in the USA).

So this is not different, but still there is the subtle but important distinction if there is even a chance that your exchange will be allowed to remain in business and at least try to continue honoring its obligations to its customers (as happened with MtGox, even after a possibly minor bank account they had in the US was seized for forfeiture for failing to have state licensing).

I wonder if it would go the same way for an exchange based in the US. Or in comparable countries, for that matter. For a UK company banking in Germany and Poland, the empirical answer is no (bitcoin-24 stopped doing business after its German bank acount was temporarily seized and hence released back to them, and their Polish bank account was simultaneously seized but at least not completely released back to them yet). Again, I wouldn't even try to venture towards judging which is better and for whom.


Wallet is encrypted and currently locked. How can I get it decrypted (unlocked) - I have my password!

You will be asked for your password when you want to send coins.

Alternatively, you can unlock your wallet for a period of time using the walletpassphrase command in the console.


Multi-signature transactions: Address based? What is the limit?

I assume im my answer that you're asking about P2SH Multisig transactions as you're mentioning multisig addresses (see What are the limits of m and n in m-of-n multisig addresses? for the 2 types of multisig schemes).

That is correct, usually what's called the multisig transaction is the one that spends from a multisig address. Note that prior to that, another transaction must have funded the multisig address.
The script length defines the limit. For each additional signature required the script will have to be longer and the limit in this case is 520 bytes. Basically, you can go up to 7-of-7 safely.


Invalid Argument Error when broadcasting a transaction with Bitcore

Either create the transaction using constructor:

var transaction = new Transaction();

or pass serialized transaction to broadcast method:

insight.broadcast(tx.serialize(), ......


How many addresses are sent in response to a getaddr message?

The result from CAddrMan::GetAddr() is fed to CNode::PushAddress, which filters out addresses the peer already has, and inserts them in a temporary buffer of up to 1000 addresses.

Later, in SendMessages(), the contents of that buffer is sent out periodically.


bitcoind: How to find the block from a TXID?

Bitcoin Core doesn't maintain an index of transactions which are not relevant to you by default to save space and processing time.

You need to run your node with txindex=1 in the configuration in order to create one, and changing the option on an existing node requires you do do a bitcoind -reindex. A reindex is equivalent to doing a full network sync again but will use all of the block files you already have on disk for the process. When this is complete you will be able to look up arbitrary TXID using the getrawtransaction RPC (gettransaction only applies to transactions in your wallet).

$ bitcoin-cli getrawtransaction 74cffe12b2d58ac2e2bc13de5519428639267e2faffb85bbbfec60d8be7cdb50 1

{
  .....
  "blockhash": "0000000000000000027d382ef7c586e0e97f623e685c9f927e78865420f72b5f",
  "confirmations": 2,
  "time": 1444654960,
  "blocktime": 1444654960
}


What's going to happen if someone has access to my Bip32 root key?

Assuming we are talking about the root private key (xprv) then yes, he will be able to steal all your current and future coins as long as you keep generating addresses from that key. It’s basically the same as him having access to your mnemonic phrase.


Bitfinex get credits and convert timestamp to JS Date

The problem is not with the timestamp, it's with your method of converting the timestamp to local time.

As this SO question describes, convert it this way:

var dt = new Date(0);
dt.setUTCSeconds(1454846632);
console.log(dt.toString());

Which prints Sun Feb 07 2016 07:03:52 GMT-0500 (EST).


Of course you can :) Bitcoin full node keeps a blockchain database in local machine.
Here is a step-by-step instruction to get the genesis transaction information.

 Find block data file.s In mac, it locates at "~/Library/Application Support/Bitcoin/blocks/blkxxxxx.dat"
 Use the given following code to decode the genesis block
 Now got every detail about the genesis block and the coinbase transaction in genesis block, including  tx_version, tx_input_num, tx_prev_output, script_length, scriptsig, sequence, tx_output_num ...

import struct # make conversation between Python values and C structsrepresented as Python strings
import StringIO # Reads and writes a string buffer
import mmap # mutable string

class BCDataStream(object):
  def __init__(self):
    self.input = None
    self.read_cursor = 0

  def clear(self):
    self.input = None
    self.read_cursor = 0

  def write(self, bytes):  # Initialize with string of bytes
    if self.input is None:
      self.input = bytes
    else:
      self.input += bytes

  def map_file(self, file, start):  # Initialize with bytes from file
    self.input = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
    self.read_cursor = start
  def seek_file(self, position):
    self.read_cursor = position
  def close_file(self):
    self.input.close()

  def read_string(self):
    # Strings are encoded depending on length:
    # 0 to 252 :  1-byte-length followed by bytes (if any)
    # 253 to 65,535 : byte'253' 2-byte-length followed by bytes
    # 65,536 to 4,294,967,295 : byte '254' 4-byte-length followed by bytes
    # ... and the Bitcoin client is coded to understand:
    # greater than 4,294,967,295 : byte '255' 8-byte-length followed by bytes of string
    # ... but I don't think it actually handles any strings that big.
    if self.input is None:
      raise SerializationError("call write(bytes) before trying to deserialize")

    try:
      length = self.read_compact_size()
    except IndexError:
      raise SerializationError("attempt to read past end of buffer")

    return self.read_bytes(length)

  def write_string(self, string):
    # Length-encoded as with read-string
    self.write_compact_size(len(string))
    self.write(string)

  def read_bytes(self, length):
    try:
      result = self.input[self.read_cursor:self.read_cursor+length]
      self.read_cursor += length
      return result
    except IndexError:
      raise SerializationError("attempt to read past end of buffer")

    return ''

  def read_boolean(self): return self.read_bytes(1)[0] != chr(0)
  def read_int16  (self): return self._read_num('<h')
  def read_uint16 (self): return self._read_num('<H')
  def read_int32  (self): return self._read_num('<i')
  def read_uint32 (self): return self._read_num('<I')
  def read_int64  (self): return self._read_num('<q')
  def read_uint64 (self): return self._read_num('<Q')

  def write_boolean(self, val): return self.write(chr(1) if val else chr(0))
  def write_int16  (self, val): return self._write_num('<h', val)
  def write_uint16 (self, val): return self._write_num('<H', val)
  def write_int32  (self, val): return self._write_num('<i', val)
  def write_uint32 (self, val): return self._write_num('<I', val)
  def write_int64  (self, val): return self._write_num('<q', val)
  def write_uint64 (self, val): return self._write_num('<Q', val)

  def read_compact_size(self):
    size = ord(self.input[self.read_cursor])
    self.read_cursor += 1
    if size == 253:
      size = self._read_num('<H')
    elif size == 254:
      size = self._read_num('<I')
    elif size == 255:
      size = self._read_num('<Q')
    return size

  def write_compact_size(self, size):
    if size < 0:
      raise SerializationError("attempt to write size < 0")
    elif size < 253:
       self.write(chr(size))
    elif size < 2**16:
      self.write('\xfd')
      self._write_num('<H', size)
    elif size < 2**32:
      self.write('\xfe')
      self._write_num('<I', size)
    elif size < 2**64:
      self.write('\xff')
      self._write_num('<Q', size)

  def _read_num(self, format):
    (i,) = struct.unpack_from(format, self.input, self.read_cursor)
    self.read_cursor += struct.calcsize(format)
    return i

  def _write_num(self, format, num):
    s = struct.pack(format, num)
    self.write(s)

def import_blkdat():
    pass

ds = BCDataStream()
file = open("/Users/junton/Library/Application Support/Bitcoin/blocks/blk00000.dat", "rb")
ds.map_file(file, 0)

# Read file
# https://bitcoin.org/en/developer-reference#block-headers
# https://en.bitcoin.it/wiki/Protocol_specification#block
magic            = ds.read_bytes(4).encode('hex')
block_size       = int(ds.read_bytes(4).encode('hex'), 16)
version          = ds.read_bytes(4).encode('hex')
prev_header_hash = ds.read_bytes(32).encode('hex')
merkle_root_hash = ds.read_bytes(32).encode('hex')
timestamp        = ds.read_bytes(4).encode('hex')
nBits            = ds.read_bytes(4).encode('hex')
nonce            = ds.read_bytes(4).encode('hex')

num_of_transaction = ds.read_bytes(1).encode('hex')
tx_version         = ds.read_bytes(4).encode('hex')
tx_input           = ds.read_bytes(1).encode('hex')
tx_prev_output     = ds.read_bytes(36).encode('hex')
script_length      = ds.read_bytes(1).encode('hex')
scriptsig          = ds.read_bytes(int((script_length), 16)).encode('hex')
sequence           = ds.read_bytes(4).encode('hex')
tx_output          = ds.read_bytes(1).encode('hex')
BTC_num            = ds.read_bytes(8).encode('hex')
pk_script_len      = ds.read_bytes(1).encode('hex')
pk_script          = ds.read_bytes(int(pk_script_len, 16)).encode('hex')
lock_time          = ds.read_bytes(4).encode('hex')

print 'magic: '       + magic
print 'block_size: '  + str(block_size)
print 'version: '     + version
print 'prevHash: '    + prev_header_hash
print 'merkle_root: ' + merkle_root_hash
print 'timestamp: '   + timestamp
print 'nBits: '       + nBits
print 'nonce: '       + nonce

print '--------------------- Transaction Details: ---------------------'
print 'num_of_transaction: ' + num_of_transaction
print 'tx_version: ' + tx_version
print 'tx_input_num: ' + tx_input
print 'tx_prev_output: ' + tx_prev_output
print 'script_length: ' + script_length
print 'scriptsig: ' + scriptsig
print 'sequence: ' + sequence
print 'tx_ouput_num: ' + tx_output
print 'BTC_num: ' + BTC_num
print 'pk_script_len: ' + pk_script_len
print 'pk_script: ' + pk_script
print 'lock_time: ' + lock_time

ds.close_file()


How to enable website users to transact with each other using bitcoins?

You need to set up bitcoind and look into accounts. If you want users to be able to pay each other in the system for anything, it is quite easy to move Bitcoins around without creating transactions simply by calling the move API. After that you just need to add the options for users to put money into their accounts and withdraw them, and you are set.

Can't really help you with Ruby-specific things though, as I don't know the language.


Testnet is not a standalone test environment. It's an actual distributed block chain like the main chain. Only, because few people are mining on testnet, the difficulty is quite low.

So yes, you can generate test coins on testnet.

Beside this, it is possible to create a very own standalone test environment, but it would require you to edit the source code. Specifically, you will need to change the (hard coded) genesis block and most probably remove the peer seeds because you don't want to bother mainnet or testnet users with your own blocks.


Bitinstant order was processed, but is not showing in blockchain - did I screw up?

I take it that this is the transaction you are waiting for: 922ce90177.... As you can see it has been submitted to the network and will eventually show up in your client as well.


Public Key VS Wallet Address - What is the difference?

Note that an address is just an encoding of some data and that not all addresses have to be the encoding of hashes.

The reason we use an address is because it is easier for humans to read, identify, and transport. But I suspect you are asking why we use the hash of public keys rather than the public key itself.

Encoding the hash of a public key as an address began with Satoshi writing the original Bitcoin client. It is likely that he chose to encode the hash rather than the public key itself in order to be more space efficient - it is easier to transcribe an encoding of the shorter hash rather than an encoding of the public key itself. Since Base58 includes both upper and lower case characters as well as having only a checksum at the end, it is annoying to read out or copy it easily, so shorter is better.

Since then, new address types that have been introduced have followed the same practice pretty much because addresses were first done this way, so why change. When P2SH addresses were introduced, it made sense (and still makes sense) to encode the hash of the script rather than the entire script itself since scripts are variable length and can be very long.

However the proposed Segwit v1 addresses for taproot will not be using hashed public keys. Rather the it uses public keys themselves encoded as bech32 addresses. Even though this is not as space efficient, it does make transactions more efficient, and does away with the suggestion that outputs might be quantum safe. Furthermore, because it uses bech32, the case-ness of each letter does not matter and since it uses BCH error correcting codes, it can tell you where you've made an error and what that letter should have been (assuming that you have not made a lot of errors). So this avoids the other issues with using Base58 encoded addresses.


The primary advantages of the UTXO model are simplicity of implementation and improved privacy.

With the UTXO model, transactions just consume some UTXOs and create some UTXOs. This tight constraint on what transactions can do makes transactions simpler and easier to execute in parallel.

The UTXO model also improves privacy by making it more difficult to associate transactions issued by the same party.

The primary advantages of the account model are improvements in transaction flexibility, account management, and multi-currency capabilities. A transaction in an account model can do much more than just consume and create UTXOs, it can modify persistent data associated with an account. This permits functions like order books and cross-currency payments.

Perhaps most importantly, it allows an account to be managed. For example, the XRP Ledger permits accounts to change their cryptographic credentials. You can have a publicly known receiving address and change the key needed to spend funds sent to that address without having to communicate a new address or move funds.

On a multi-currency system, accounts can specify assets that they're willing to accept as payment. So, for example, if I owe you US dollars, I can check your account settings to see what assets you accept for dollar payments. The enables the XRP Ledger's foreign asset system, enabling the largest decentralized exchange in the world.

Lastly, an account model makes it easier to bring new servers up. The number of accounts will generally be much less than the number of UTXOs in a comparably sized system. This means less data needed to bring on new nodes.


What are the exact steps for creating a transaction and having a valid block?

I send 10BTC to Batman.
  Because I have send BTC, a transaction is created in system.
  This transaction is send to all nodes from network (all users)

That is correct so far

  After transaction arrives to all users, the transaction is added in a queue where the miners take take their transactions.

Yep, although its not really a queue because miners don't necessarily have to take the first transactions first. Its called the mempool, and its just a bit collection of them, with no enforced order.

  A miner take transaction, process it (proof of work) and creates a block with more transactions.

I'd just like to make it clearer that the proof of work is the name given to the hashing of the entire block, proof of work is not the verification of the transaction. Verifying the transaction doesn't take much work, only creating the block does.

  After all the transactions are validated by miner, the new block is send in the network for check.

After all the transactions are validated by the miner and the miner has found a valid proof of work block, that new block is sent to the rest of the network. Just valid transactions alone does not make a valid block. You are missing the idea of "Computes cryptographic hashes over and over until if finds one 'good enough to count'" that you mentioned. That is the proof of work.

  How does each user check this blockchain (divide the blockchain and check each transaction if the transaction from the blockchain is the same with the one that he has (because first transactions are send to all the users from p2p network and after that are send in the queue to be process by the miner. This is how user is able to compare the transactions))?

Users can just compare the transaction hash with the ones in the blockchain, because the hash is a deterministic "summary" or digest of the transaction. The same transaction will always have the same hash, but two different transactions will have different hashes. Full nodes always validate all the transactions in the new block when they receive it anyway, they don't just trust the miners.


how to track sendtoaddress / sendmany in case of network failure

In the event that bitcoind completes a transaction, but the RPC response is lost, the transaction details will still remain available. The wallet and transaction database is updated directly by bitcoind, and will be updated regardless of the RPC state.


Are pools share rewards equivalent to the power/hash rate input of a mining machine

Yes, it is. This is done by the pool having a much lower difficulty than the network does. If your block meets the pool's difficulty, you earn a share (but the block isn't really used); if it also meets the network's difficulty, then it is released to the network. Finding shares is random, and the payout scheme can mean that you earn more or less coins for a share, but over a little time it averages out so that you are paid proportionally to the hash rate that you bring.

As a simple example, a pool that uses a proportional split scheme would split the mining reward to the miners in the pool based on how many shares they earned in the course of mining that block. (This scheme is not good, because it allows pool hoppers to earn more at the expense of other miners, so other schemes like PPLNS are more common; but that's more complicated so I'll leave out the details.)


What are some Bitcoin / blockchain projects that are actually doing something?

My favorites,

Ether Delta(https://etherdelta.com),  Decentralized exchages controlled by zero entities.

Augur(http://augur.net) Decentralized prediction market/betting company.

So many more, at https://www.stateofthedapps.com


Aren't the Bitcoin receive addresses the public keys?

No. There are multiple kinds of addresses in common use:
A Pay to Public Key Hash (P2PKH) address, beginning with a 1... uses a Hash160 (Sha256 followed by RipeMD160) of the public key. The public key is not revealed until this output is spent, as the spending transaction will include the public key in its scriptSig.
A Pay to Script Hash (P2SH) address, beginning with a 3... uses the Hash160 of the redeemScript, which is not part of the scriptPubKey. The redeemScript is part of the scriptSig which spends the output.
The hashes of the above two are then encoded using Base58Check to generate the address.
There are also Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH) versions, which are for post-segwit transactions where the witness is a separate part of the spending transaction. These both begin with bc1..., with the difference between the two being the length of the hash. These are both encoded using the bech32 encoding to give the final address. The publicKey again, is part of the spending transaction, but is instead included in the extra witness field rather than the scriptSig.
There does exist a legacy P2PK (Pay to Public Key) output type, but this is seldom used. In this, the public key was included directly in the scriptPubKey.
In the others besides P2PK, the public key is not revealed until an output is spent. There is no way to know a public key from the hash alone, as the hash is a one-way function.


Does blockchain.info wallet or mycelium wallet use Bitcoin core?

When you use Mycelium you're not running a node on your phone. Instead they run a few Mycelium servers, which include Bitcoin core nodes. They will have updated by now (probably around the date of this alert).

Blockchain.info is notorious for running old or non-standard node software causing all kinds of corruptions in their block explorer, but also sometimes in their wallets. But even for them I'd be surprised if they haven't updated by now.

In general this alert is only still applicable if you're running your own node with one of the old versions mentioned.


Clients do not need to keep the entire blockchain. There are going to be historical transactions that no longer have any coins associated with them. This means that clients could, today, purge a large chunk of the database.

This was mentioned in the original whitepaper:

  7. Reclaiming Disk Space

  Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.


The pruning works after full node synchronized only !!!!
You can set it prune=550 only after that you have full node.
Full node, then type prune=550 in conf file, then shutdown, then restart.
Hi.


Can bitcoins be "sold short"?  Or are there "put" options?

Not only will Bitcoins soon be able to be sold short through several exchanges, but once that service is available, Bitcoin banks that pay interest will be possible.

A Bitcoin bank could pay interest on Bitcoin deposits by converting the Bitcoins into the least inflationary national currency available, investing those funds in loans or businesses, and using the profits to buy back more Bitcoins later to pay back depositors.

However, this plan has one flaw -- what if the price of Bitcoins goes way up, beyond the interest you can collect. You would then take a loss when you purchased back Bitcoins to pay back your depositors.

Normally, you would offset this risk by holding Bitcoins. But that would defeat the entire point of investing them. So you need some way to make money and risk money as if you were holding Bitcoins without actually holding any bitcoins. How can you do that?

And the answer is, you offset the risk that Bitcoins will go up in value by selling shorts. Selling shorts is like holding Bitcoins without having to actually hold them, allowing you to make money if they go up and lose money if they go down just like someone holding Bitcoins would. If Bitcoins go down, you lose on the shorts but make it up by making extra profits when you buy back Bitcoins to pay depositors. If Bitcoins go up, you lose when you buy back Bitcoins, but make it up on the shorts.

With the right combination of shorts, currencies, and investments, this should make the risk associated with interest-bearing bank accounts denominated in Bitcoins no greater than the risk with other currencies. (And if you sell the shorts directly to investors, you can make a profit on them as well, taking the commissions.)

It is entirely possible that this is part of the reason the exchanges are considering selling shorts. Not only would they pocket the commissions, but they could safely convert a fraction of the many, many Bitcoins they're holding into interest-bearing accounts denominated in national currencies, pocketing the interest.


When is the version 0.7 of the standard client scheduled to be released?

When it is ready.   There is no "schedule" and no set release date made in advance.

Once a release candidate is out, generally the only changes are "showstopper" bug fixes.

Each release candidate needs to be tested.  Only if testing occurs and no showstoppers are identified does the last RC become tagged as the final release.

Here's some steps that happen during building the release candidates:

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


How do miners handle transactions when a different miner creates a new block?

Not all blocks are mining the same transactions in their respective proofs-of-work. Each miner collects enough transactions via gossip until they reach the block size limit. Not all transactions will make it into a certain block, so those will be more likely candidates to make it into the next block. Miners decide which transactions to include in a block with the following equation:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes


Is there a good blockchain explorer like blockchain.info available for bitcoin cash?

Try Blockchair. It is a blockchain explorer for both Bitcoin and Bitcoin Cash.


Do we need to maintain the ability to do a reorg over 100 blocks?

If the protocol were changed to use this, then a UTXO database based on the results of the blockchain up to the checkpoint block could replace the gigabytes of blockchain that we currently use for validation.

You can already do something similar to this by turning on -prune. That can cause your node to stop working if the reorg is more than 288 blocks, though as you noted, that doesn't happen often.

That still requires you to download the entire blockchain in the first place, of course.

  If we decide that "the chain with the most difficulty" means "the chain with the most difficulty over the last N blocks" and pick a good N, it could make some things simpler AND make transactions at a depth of at least N immune to a 51% attack. Thus, it limits the value of cornering the market in hashing power. Such "cornering" could happen without being noticed, so it has begun to worry me.

Suppose a node joins later, after the new chain has been published. From its perspective, the two chains were created at the same time. Because of that, it would naturally choose the one with more work attached to it.

So how do we avoid that? This is a problem that's a lot more complicated than it looks.

  The protocol requires that freshly generated coins wait 100 blocks before they can be spent in order to avoid polluting bitcoin addresses with bitcoins that are "uncreated" by a reorg that invalidates the block that created them.

Sure, but we're talking about two levels of consequences. In one circumstance, one person on the network loses money. In the other, the blockchain is forked forever.


This sounds like a power problem to your erupters most likely. Can you show me the config file or the options you are enabling? In particular, the -scan option.

Further, you might verify you have a powered USB hub and try using a powered USB port if available; it only takes a little power to run them, but a little power to stop them. I also power my rasp pi through a wall charger also, rather than powering it from the usb hub.

I have had much more success running BFGMiner with Erupters and Antminer U1 USB sticks with a Pi and usb hub to control (and using Minepeon on the rasp pi). The command to start BFGMiner and scan for erupters etc and create a log in case you do have problems is:

bfgminer –o [pool] –u [user] –p [password] –scan-serial erupter:all –icarus-options 115200:1:1 –icarus-timing 3.0=100 2>logfile.txt


Bcoin wallet always has unconfirmed balance

This probably helps you:

https://github.com/bcoin-org/bcoin/issues/163

  What we really needed was a "real-time" balance, and "confirmed" balance.
  So the simplest solution was:
  confirmed = what is on the blockchain
  unconfimed = what is on blockchain + mempool
  Essentially unconfirmed is your real-time balance. confirmed is your blockchain-secured balance.


How does an individual access the Bitcoin Core repo and contribute to it in the case that GitHub boots Bitcoin Core or the individual off GitHub?

Nothing interesting happens if github bans bitcoin, the repository will be uploaded on a different host. Git is a decentralized application and several mirrors exist already. The contributors also have local copies of the repository so no code will be lost.
The biggest problem would be that the github issues and comments will be lost since they are a github feature (not part of the git repository).


How to re-connect to `bitcoind -printtoconsole` after socket timeout?

I don't think you can reconnect to it easily, but for next time, you could create a screen session and start bitcoind inside of it. That way you could reconnect to it with screen -r


This is a known and notable problem with Antminer U3s.  It's discussed at various locations around the Web.

The design couples the USB and miner +5V power rails, which is not good practice.  USB interfaces should be both electrically and optically isolated.  When a unit goes ZOMBIE, it generally requires unplugging and replugging to restart it, which fits with the above.  Some commenters claim that cutting the power lines in the USB cables improves reliability.

However, the maintainer of cgminer comes right out and says that the design is inherently unstable.  In light of my own experience I agree.  I ran three Jalapenos on a dedicated Pogoplug linux system for a year with no problems.  Two U3s have been on the same Pogoplug for two weeks now, and neither has run for 24 hours straight.  They're going back to the seller tomorrow.

Long and short of it, if you get a stable unit it will serve you well.  But most of them are unstable to at least some degree.


You are assuming that each mining pool is hashing the same block.  This is not the case.  Each pool has its own block, with its own set of transactions, put into its own order. Mining isn't about finding the only block that is able to be the next block, just a block that follows the protocol rules.

Furthermore, mining pools are constantly updating the block headers that their nodes are hashing, to include more transactions that they just heard about.  Because all pools, and even all nodes, are trying to find a nonce for different block headers, it's not always the most powerful pool that wins.  It becomes random.


Electrum Wallet: zero mBTC balance after sweeping private address

obv i would check the paper wallet address to make sure it is empty.

if it is, then i would input the tx id or the btc address into Blockchain and see what's up.
if you swept it correctly, then the funds are there somewhere.

also, if the amount swept was a lot and your fee was puny, be prepared to wait a very long time.

i see SO MANY NOOBS try to transact 5/10/40 btcs at once and pay a fee of $3!!!!!
not saying you did that....just saying


Is our hardware wallet safe if the PC or Mac has 3rd party apps?

Typically, the signing is done on the device and the private keys never reach the computer. This means that the computer can never generate and sign transactions on its own
A wallet like Trezor (T) shows the destination address from its screen so that you press one of the buttons on the device itself. This makes it impossible for the computer to make the device sign a stealing transaction, because you would see that the destination address is not your intended recipient.
I would use Trezor T with any online computer.


How can address' hash160 be used to determine information for malicious purposes? (Ie reusing of the same address)

If your PRNGs are good, you don't lose any security by using the same address any number of times. Some websites claim that addresses should not be reused because that will make your bitcoins vulnerable to quantum computers and/or some newly discovered weaknesses in ECDSA. However, both of these scenarios are unrealistic at the moment, and I think that if they do become realistic, this will be such a big problem for the world's cryptography that you won't be the first victim (unless you are Satoshi Nakamoto).


How does Mimblewimble's security model compare to Bitcoin's?

Commenting on the overall security model is a much more complex answer as many moving parts are involved, from initial blockchain syncing to cut-through. But to answer your specific questions:

Quantum computing

MimbleWimble is not very well prepared for quantum computing as it's intricately tied to Elliptic Curve Cryptography (ECC). But the full picture is a little more complex.

First, one has to define "quantum computing" further. Shor's algorithm would require several hundreds of qubits to break ECC. Modern quantum computers with higher qubit counts rely on quantum annealing, which is a different "kind" of quantum computer much more limited in function, and can't implement Shor's algorithm.

Second, there's early indication that quantum-resistant algorithms may exist with properties similar to ECC that could be used for MimbleWimble. They're mostly untested in the field, so it will required some time, but the above points shows we do have some time.

Overall, quantum computers that can break ECDSA are still years away. So starting with ECC which is well proven and migrating to quantum resistant algorithms when they're mature seems like a good approach.

Miners trust and "Classic" Bitcoin attacks

MimbleWimble has the same miner trust model as Bitcoin, and the same exposure to 51% attacks and DDOS (although in the case of DDOS resistance is more implementation specific than algorithmic). MimbleWimble is more resistant to Sybil attacks than Bitcoin because it's impossible to fake the current chain state.

Light Clients

At this point, light clients are completely unspecified. However assuming a UTXO set commitment in the header and a few other sane measures, tricking a client into trusting an invalid transaction would be extremely hard.


Is it correct to assume that the price of cloud GH/S will vary proportionally with the difficulty change?

The price of CEX.IO's GH/S asset is based on the total future expected payout of a Gh/s of mining hardware, factoring in management fees and the time value of money.  The current price already factors in future difficulty increases, as these are predictable and expected events.  The price should not move significantly when the difficulty adjusts, as the occurrence and magnitude of the adjustments are not a surprise to any informed participant in the market.


Internet speed required to run the Bitcoin client

Internet connection speed has to be fast enough to download new blocks as they get mined. With current transaction rate it requires 1-2 Kb/s. But faster connection would help to reduce chance of double spend attack if you run retail business and accept transactions with 0 confirmations.


Relative performance of various mining software?

I think the closest thing is the bitcoin mining hardware comparison:

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

Miners have different performance with different hardware architectures, so which miner is fastest for you depends on which hardware you have (AMD GCN/VLIW4/VLIW5, NVIDIA, different FPGAs).

It might be an idea to start a wiki page for a mining software comparison. Alternatively, adding more measurements on the hardware page could do the same thing (but might bloat the page a bit).


The utxo set is indexed by transaction_id + out_index from Bitcoin Core 0.15 onwards (just by transaction_id from 0.8 - 0.14). So in order to get all UTXOs for a certain height you need to parse the whole set and filter it by height.

There's no way of doing so with bitcoin-cli AFAIK. You can do it by using STATUS (a tool I'm coauthor of). Feel free to ask for support if needed.


bech32 addresses for segwit support in mycellium and coinomi?

Mycelium doesn't support segwit at all right now. I don't know about Coinomi but it looks like they support Segwit (at least receiving from a segwit address) but not BIP 0173. Since neither support this format, there's no way to generate bc1~ address within the wallet, so no way to send any bitcoin to them using this format.


This is undoubtedly yet another scam. It's intent is the only question.

Your first port of call seems obvious; Google Is cointellect a scam?
Answer: yes.

Explanation:

Pooling the CPU resources of every miner using this software would be a fraction of the power for even the oldest ASICs.

As an analogy, the site is saying individuals need to dig an open cut mine with their spoons while mining rigs (ie 50ft tall trucks) are carting away pay dirt to process. Pool all the spoons you like, there's simply no feasibility of any reward - but assuming the improbable, if a block was mined, how is the ฿25 distributed? If you can't answer that then that's indicative of a scam.

As far as the "debate" about some users saying they've seen returns; this is how scammers operate. They use shills (fake positive reviewers) claiming profits which never occurred.

Whether the scam is fruitlessly using CPU to try and mine is possible, but it's astronomically more likely the software is a vector for Trojans to steal your Bitcoin. These types of malicious "mining" software are simply identifying newbie Bitcoin users, infiltrating the OS with a Trojan/RAT/keylogger, then stealing your wallet / private keys if/when they become available.

Assuming a Windows installation, you're basically screwed. The software likely already has your login info, passwords, private keys, credit card details; any and all are likely compromised. I'd immediately disconnect from the Internet and do a fresh install of your OS.

Please, research these things beforehand because so many of these services are popping up. Let's hope the Bitcoin Savings And Loan retroactive prosecution of running a Ponzi scheme sets a precedent and scares some would be scammers straight.

EDIT:

Virus analysis of software
SSL certificate owned by unknown
Company name similar to banking conglomerate but not that company

Take this info as you like. It's fact. Not libellous.


How does a new node know where to connect to initially?

There are a number of DNS seeds hard coded into the Bitcoin client.

It's not really possible for these to be banned. The way DNS seeds work is by returning multiple A records for the DNS seed hostname, with each A record belonging to a node. In essence, they act as name servers, and use the existing DNS specification to provide nodes with the information.

It is possible for a network to tamper with these responses, or prevent the DNS lookup to begin with. In such a case, one could manually use the addnode option in Bitcoin.conf to connect to one or more peers directly. Once you are connected to a few peers, they will share their peer list with you, and you can connect to the other peers on the list, and get additional peers from them, and so on and so forth.


Why is CPFP (Child pay for parent) immune to double spend?

If you're doing CPFP right, The two transactions you sent are both originating from the same UTXO, but one spends the output of the older transaction with a higher fee.

If the miners want to get the fees of the last transaction ( the transaction with the higher fees), they will need to mine the first one aswell.

So, if your first transaction gets processed first, it's probably just a matter of time before your second one gets confirmed (due to the high fees), leaving you with the 4 bitcoin - (fees).


Is it possible to send BTC out of an exchange account, in order to bypass the private key management system

Yes, all exchanges allow this.  They have to, because this is how you withdraw or spend coins from the account.  It's not any kind of sneaky workaround, just normal behavior.

However, you can only trade using coins (or dollars) that are held on the exchange, so if you do this, you won't be able to sell them on the exchange until you send them back (redeposit).  This incurs another transaction fee and takes time for confirmation, so it's not an option for people who want to be able to trade rapidly or sell their coins quickly when the price moves.

(Decentralized exchanges may be an exception.  I know less about how they work.)


Both options, bitcoind and blockchain.info API are equally vulnerable.

When the attacker gains to access to your server, they can empty the hot wallet through an API call, regardless if they or your server has access to the private keys. This API call can be blockchain.info API call or bitcoind JSON-RPC API call.

The best practices to strengthen a bitcoin service against server compromising attacks

Use separate hot and cold wallets, only manually top up hot wallet from the cold wallet. You will lose the ability to withdraw everything at any time, without manual interaction from the team, but this is the only way to prevent losing everything at once.
Encrypt your server and use bare metal servers, so that your server is protected against physical attacks and malicious hosting provider attacks. You can only put relevant config files containing the API tokens to the encrypted partition and symlink the config file to the right location after manually decrypting the server on boot. This way anybody gaining the physical or service port access to the server  is less likely to gain withdraw ability.

Here are some other best practices for operations security.


A P2SH locking script on an output has the following structure:
         Output (scriptPubKey)
--------------------------------
OP_HASH160 <scripthash> OP_EQUAL

The address comes for this comes from the <scripthash>, creating a "3address". This is the standard format for a P2SH, so you can identify it and work out the address from there.
That's all you need to get the address, but explaining a little further...

Interestingly, the <scripthash> can be the hash of any kind of script you like. However, it's most commonly used for putting the hash of a P2MS in there. So when you come to unlock this script, the scriptSig may look something like this:
          Input (scriptSig)
-------------------------------------------
OP_0 <signature> <signature> <redeemscript>

What you're seeing here is basically a complete script for what would have been a classic P2MS scriptPubKey and scriptSig, where the <redeemscript> is a data push of a normal script with opcodes.
          Input (scriptSig)
-------------------------------------------
              scriptSig       scriptPubKey (as a data push)
---------------------------- --------------
OP_0 <signature> <signature> <redeemscript>

With P2SH it's like you have a complete scriptSig+scriptPubKey contained inside the scriptSig, and it can contain any script so it doesn't have a standard form.
Anyway, this complete P2MS script starts with a OP_O, because all P2MS scriptSigs have to start with that due to the off-by-one bug that the OP_CHECKMULTISIG opcode. This is nothing to do with the OP_0 you get in Segwit scriptPubKeys.
When this script executes, the <redeemscript> will firstly be hashed and compared with the <scripthash> in the output to make sure it matches. If it does, the <redeemscript> is deserialized to see the opcodes:
      Input (scriptSig)
-------------------------------------------
              scriptSig       scriptPubKey
---------------------------- --------------
OP_0 <signature> <signature> OP_2 <pubkey> <pubkey> <pubkey> OP_3 OP_CHECKMULTISIG

So this is what you would see on a classic P2MS output, but this just happened to be wrapped in a P2SH script because it's cheaper for the sender. So this is the standard format for a P2MS: (OP_N <pubkeys...> OP_M OP_CHECKMULTISIG).
This particular scriptPubKey does not actually have an address. There are <pubkeys> in there, but it wouldn't be technically correct to say those <pubkeys> have an "address", because an address refers to a specific locking script pattern, and is not just the friendlier version of any <pubkey>.
Examples:

P2SH with a P2MS inside it: https://learnmeabitcoin.com/explorer/transaction/d3adb18d5e118bb856fbea4b1af936602454b44a98fc6c823aedc858b491fc13/output/0#scriptPubKey
P2SH with a non-standard script inside it: https://learnmeabitcoin.com/explorer/transaction/7d46745463a28049cb93d2c964320912d9c296c1038cb24cc3716255c397a87f/output/1#scriptPubKey

Links:

https://learnmeabitcoin.com/guide/p2sh
https://learnmeabitcoin.com/guide/p2ms
https://learnmeabitcoin.com/guide/address