Current blockchain hot topics in research

I think it's scalability. The cost to generate a block is getting more and more expensive. Couple months ago, CryptoKitties caused Ethereum network congestion due to the surge of transactions. For real world application, I think blockchain must be able to handle high volume of transaction. This can be achieved by reducing the cost to generate a block. AFAIK, some blockchains are developing proof-of-stake algorithms replace the old proof-of-work one.

You may interested in Ouroboros proof-of-stake algorithm, which is implemented by Cardano. Ethereum is also working on their own implementation - Casper


How altcoin wallets import private keys is up to the specific altcoin, so I cannot provide a blanket answer for all of them.

However, I can tell you that this functionality is not determined by the hashing algorithm used for the altcoin's proof-of-work.  That is independent of the Wallet Import Format, which just so happens to use SHA256, and does not use SHA256 because that is what Bitcoin uses for proof-of-work.

My guess is that most altcoin's (but not all) support their own version of WIF, but with a couple of likely differences.

First, the altcoin may not use the same asymmetric cryptography for creating addresses, which means that private keys might not be the same length as they are in Bitcoin.  Since the private key is the input of WIF, this can have a consequence on the end result.

Second most altcoins will probably use a different network identifier that gets pre-pended to the private key in step 2.  Bitcoin's mainnet uses 0x80, but an altcoin could use whatever value the creator felt like.  Perhaps it was changed...perhaps is wasn't.

Other than that, I would guess that most Bitcoin-clone altcoins use the same process for importing private keys.  It is also possible that the checksum is created using a different hashing algorithm than SHA256, but that algorithm in no way has to correspond with the proof-of-work hashing algorithm of the altcoin.

Check the docs on the altcoin in question to find out for sure.


Are there any linux distros that have the bitcoin client pre-included?

LinuxCoin is such a distro (based on Debian).


I for example own 10 BTC does that mean, in some Blocks in the valid part of the blockchain is written, that I received at some point in time a certain amount of BTC? How do I prove that the Transactions in this block belong to me (without loosing ownership).

Essentially, yes. Owning BTC simply means that one or more transaction outputs somewhere in the chain exist, that are spendable by you. In a normal case, this means that you have control of the private keys required to spend these outputs.

To prove you own them, you can sign a non-transaction message using your private key. This signature can be verified against your public key, and the public key can be verified against an address, thus proving that you own the outputs associated with that address.

  How hard is it to find all transactions in a chain which belong to me

If you do not know the transaction IDs, the merkle tree will not help. The merkle tree is only useful if you want proof that a known txid is in some block. If you only know the addresses that your outputs are at, but not the txids, you must scan the entire chain and match the output scripts against your addresses. This will have a worst case of O(n).

  Could everybody check my amount of bitcoin if he knows my alias or whatever is used to mark my transactions as mine.

If they know which addresses belong to you, yes.

  Could I just spend someone elses coins?

If you are able to satisfy the output script requirements, then yes. For regular transactions, this would imply that you have been able to compromise the keys owned by someone else.


Great question!

I'd take a look at multi-sig construction in Bitcore, and pair this with bitcore-wallet-service.  Some combination of these two items, with an agent to act as a signatory for a third key, would build a powerful escrow service in very short order.


What percentage of newly created bitcoins have never been moved?

As of block 445550 (december 28, 2016, 19:14 UTC), there are 55450 blocks with unspent coinbase outputs, with a combined value of 1854952.32263065 BTC.


What OSes don't yet have Bitcoin clients?

The bitcoin source is free derive and redistribute. I believe some microarchetectures (some flavors of ARM?) are currently unsupported.


As the operator of the site I will try and answer the first question.

Server Side

The site currently runs on 4 dedicated servers, hosted in a locked cabinet. All servers run  behind a dedicated cisco security appliance with intrusion detection. On the servers themselves various "booby traps" are set to alert the webmaster if an intrusion is detected.
The java code deployed to the Site is deployed in a single war (zip) file. Each server monitors the checksum of this file to detect any unauthorised changes to the code. In order to make reverse engineering our encryption schemes more difficult the the java class files are obfuscated using proguard.
A copy of every wallet is stored all our servers. Additionally the latest 50 versions of a wallet are stored on Amazon S3 and can be restored from the [Import / Export] section.
The server side code that handles wallets is open source.
The site is not vulnerable to CSRF requests as no login details or sensitive data is ever saved in session cookies.
In the time the Site has been running there has been handful of XSS vulnerabilities reported. None of these were on a wallet page and could not have resulted in any direct loss of funds.

Client Side

The Site uses javascript the encrypt and decrypt wallet client side in the user's browser. The encryption is done using AES-256 which is likely to be secure for the foreseeable future.

Wallets are simply json files containing private keys. The entire json file is encrypted by the users browser before being uploaded to us. So when a wallet reaches our server is appears as random Base64 string. This means we cannot view your balance, see your transactions or addresses and cannot make transactions on your behalf.

The encryption is only as strong as the users password. The minimum password length is 10 characters however if the a weak password is chosen e.g. "1234567890" using a dictionary attack the wallet would likely be broken quickly. Rainbow tables will not work as each wallet is prepended with a unique salt combined with the users password using PBKDF2 to derive the actual encryption key.

As everything is done using javascript in the site is particularly vulnerable to browser exploits including malicious browser extensions. Modern web browsers are much more secure than the internet explorer 6 generation.
The private keys in a wallet can be "double encrypted" using a second password. One password is then required to login and another password is required to send funds. This makes wallets significantly harder to brute force and also makes key logging more difficult.
If our servers were compromised the attacker could theoretically alter the javascript files to intercept the users password next time they login. For this to be effective the attack would have to go unnoticed for an extended period of time. In addition to the server side checks we perform there is also the My Wallet verifier browser extension which can be optionally installed for added security. Before login it will transparently verify all the javascript files running on the page match those hosted on github. If any errors are found the extension will prevent the user from logging in.
You can backup a wallet via Email, Dropbox, Google Drive and Download. With a backup funds can be accessed without blockchain.info using the multibit desktop client.
The Site supports a variety of two factor authentication methods and the ability to lock down a wallet to a specific ip address. We will not give out your wallet to anyone who cannot authenticate themselves fully, however we cannot prevent someone from using your wallet if they gain access to it another way. For example if you keep a wallet backup in your email account and that is compromised.

This has got a little technical but it isn't an easy answer. There are many factors involved including the security of your own computer. The site has been running for over a year and currently hosts nearly 40,000 wallets. There have been reports of some individual wallets being compromised (reusing passwords) but no major security incidents.

Finally a couple of recommendations for using our service:

Upon sign up print a "Paper Wallet", store it somewhere safe and hidden.
Never reuse the same password on another site. Or if using double encryption it is acceptable to use a slightly weaker main password but ensure the second password is unique.
If storing large amounts generate a private key offline (bitaddress.org is great for this). Print it on a paper wallet, then import the address as "Watch Only" address. When you attempt to spend the funds you can scan the private key off the paper wallet using a webcam.

In future multisig will be available for even greater security but this isn't quite ready yet.

-Ben


How to receive newly broadcasted transactions immediately with bitcoin-core RPC?

You can use the ZMQ interface to receive a ZMQ notification when a new transaction is received. You can have it give you the txid, the raw transaction, or both.


Is the ordering of blocks in the rev*.dat files same as the blk*.dat files?

No.

Block data is written (appended to) blk*.dat files whenever a block is received from the network (assuming things like PoW and a few other sanity checks pass). As blocks are received in parallel from multiple peers, their order on disk ends up being chaotic.

Undo data is written when a block gets fully validated. As full validation requires validation of all parent blocks first, the order of undo records tends to be much more monotonic. However, it is not guaranteed to be be perfectly continuous either, as reorganizations can cause discrepancies. If a received block never ends up being part of the active chain, it will never have an undo record, despite the block data being present.

The only guarantee is that block data and undo data is stored in matching files (e.g. a block which is stored in blk00473.dat will have its undo data in rev00473.dat).


Does an unopened encrypted Electrum wallet relay its addresses/transactions to nodes?

No because until you provide the password at the start Electrum can't decrypt your wallet file so it doesn't know your addresses and can't query a server about related transactions. This only applies if you are using full wallet file encryption. You know you are doing that if you are asked a password at the start and not just when you try to spend your coins.

Another way is to go to wallet menu > password. The encrypt wallet file option should be checked there. A third way would be to go to file > save copy and examine the saved file in a plain text editor. If you find that it's all random unreadable characters (ciphertext) and not JSON code then you have full wallet encryption.

BTW you can configure a socks proxy under tools > network > proxy tab. If you configure a socks proxy that can only be accessed via your VPN you will never make the mistake of connecting without a VPN. However, note that a VPN does not anonymize you. It just prevents censorship. If you want anonymity use Tor but also note that all bitcoin transactions are public so it can never be truly anonymous.


How harder is it on average to find a block with one more zero in its hash?

From Applied Cryptography, by Bruce Schneider (pp. 157-158):

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10^-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10^-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×10^41 ergs. This is enough to power about 2.7×10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
But that's just one star, and a measly one at that. A typical supernova releases something like 10^51 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Essentially, the laws of physics prevent the existence of classical computers which can count to 2^256, let alone break 256-bit encryption. Moore's law alone won't ever stop Bitcoin's proof of work from working.
There are two ways around this, however. The first is a break in SHA-256. This is quite unlikely, as Bitcoin uses twice as many rounds of SHA-256 as the usual implementation, as block headers are actually hashed twice. If SHA-256
is ever broken, Bitcoin will actually probably be one of the last programs to suffer from the break, and will have ample time to switch algorithms.
The second way to get around the aforementioned laws of physics is with a computer not made of bits; a quantum computer. Any function can have its domain searched in O[N^(1/2)] on a quantum computer by Grover's algorithm. For SHA-256, with a domain and codomain size of N = 2^256, a string of zero bits twice as long as that of a classical computer running at the same speed can be found in the same time. This would still not be enough to exhaust the remaining bits, and in any case, an attacker with a quantum computer would make much more money by cracking Bitcoin public keys and stealing their balance.
EDIT: Fixed exponents getting mangled in the copy-pasting from PDF.


You can't.
Bitcoin Scripts have no access to the block hash, and cannot determine if it is odd or even. You would need an external oracle for this.


There is no such thing as a transaction "balance".  I am going to assume if I jump right to the answer it won't make much sense so the first two sections are to make sure we are how Bitcoin "really works" (at a very high level abstracted view).  We need to speak the same language for the answer to make any sense.  For this question the two required concepts in how Bitcoin really works that need to be understood are inputs & outputs, as well as where transactions are recorded.

Inputs & Outputs

Bitcoin works on the concept of discrete inputs and outputs not spending part of a balance.  All transactions have as their input a reference to a previous unspent output.  The transaction records one or more new outputs (which are referenced in the inputs of some future transactions).  Outputs are "spent" when they are referenced in a new transaction.  Outputs can only be unspent or spent, they can't be partially spent.

Wallet balance (or address balance) is an abstraction to help us humans and make Bitcoin more like conventional payment systems.  Balances are not used at the protocol level.  When the wallet indicates your confirmed balance is 1.2 BTC it is saying that the sum of the value of all unspent outputs in the blockchain which correspond to public keys it has the private key for total 1.2 BTC.  In other words the wallet is computing the total value of the outputs which it can spend which requires a) the output be unspent and b) the client has the private key necessary to spend it.

Storing Transactions

All confirmed transactions become part of the blockchain.  Clients validate transactions and blocks; only valid transactions and blocks are added to the blockchain.  For the purposes of validating transactions and computing available balances only part of the blockchain is needed and that portion is called the UTXO (Unspent Transaction Output Set).  This is a subset of JUST the unspent outputs.  As all future transactions will reference unspent outputs as their inputs only the unspent outputs are needed for validating new transaction and computing the balance (which is another way of saying the total value of outputs which "can" be used in new transactions).

The UTXO is much smaller than the entire blockchain (about 15% of total blockchain right now and that will shrink over time).  It may not be immediately obvious but the number of Bitcoins in the UTXO is always equal to the number of mined Bitcoins.

Unconfirmed transactions are not part of the blockchain (or UTXO).  Clients maintain an unordered list of all the unconfirmed transactions they are aware of.  This list is called the memory pool.

Computing "Balances"

The creation of the UTXO makes computing balances straightforward.  The UTXO contains all unspent outputs however your client can only spend the subset of those outputs which correspond to public keys that it has the private key for ("your keys").  This subset has no official name however the RPC call to output this list is listunspent so I will call it the listunspent set.

The wallet uses the listunspent set and memory pool to determine the current balance.  In reality wallets compute this in "real time" as changes to the memory pool or UTXO occur (i.e. when the client learns of new blocks or transactions it records them and then makes changes to its reported balance if any).  For the sake of brevity I will just show how to get a "snapshot" of the current balance.  There is a confirmed balance and an unconfirmed balance, clients often show a reduced-current balance to simplify things for users.

Confirmed Balance

The confirmed balance is the sum of the value of the "listunspent" set.  Example: the listunspent (outputs in UTXO which client has keys for) has 20 outputs and combined they have a total value of 1.2 BTC so the confirmed balance is 1.2 BTC.

Reduced-Confirmed Balance

Client usually do not show the "real" confirmed balance because users are more interested in what they have available to spend.  Transactions in the memory pool which have inputs that reference outputs in the listunspent set technically have no yet reduced the confirmed balance.  In most cases they will eventually confirm so clients will remove these outputs when computing the "confirmed" balance.  The "confirmed" balance in most wallets is actually this reduced-confirmed balance.  It is done to abstract the way Bitcoin really works.  If it wasn't then the confirmed balance would not reduce until a transaction was confirmed which might seem confusing to a user (they have 100 BTC, spend 1, it still shows 100 BTC).  A client could break this down into "confirmed balance", "reserved for unconfirmed transactions", and "available balance".

Unconfirmed Balance

An unconfirmed tx "to" the client will not be in the UTXO yet.  It will however be in the memory pool.  The sum of all the outputs (which the client has keys for) in the memory pool is the pending balance.  Those tx will either be confirmed (the tx and output is removed from memory pool and added to the UTXO) or they will be dropped.

Handling Change

Due to the way Bitcoin handles "change" (outputs can be partially spent so the unused portion is sent back to the user) the simplified example above while accurate would be confusing to the user.   Most wallets "cheat" and include the unconfirmed change outputs in the "reduced-confirmed" balance.  This isn't a requirement however not hiding this aspect from users may lead to some unexpected behavior.  Imagine a client with a reduced-confirmed balance of 100 BTC and a pending balance of 0 BTC.  The user "spends" 1 BTC however the outputs referenced in the new tx total 5 BTC.  This means the new outputs are actually 1 BTC + 4 BTC "change".  If balances weren't modified to "hide" the change, after the spend the user would see confirmed balance of 95 BTC and a pending balance of 4 BTC.


It appears to be a hash160 of a public key. Generate an address, then either take the RIPEMD-160(SHA256(key)), or paste the address into this calculator: http://bitcoinvalued.com/tools.php


Wallet backup in heterogenous environment

Assuming you mean the wallet.dat file, yes, you can do that. There are no Operating System restrictions on the wallet.dat files (or any other files in the Bitcoin Core data directory).


Simplified Payment Verification:

  A Bitcoin implementation that does not verify everything, but instead
  relies on either connecting to a trusted node, or puts its faith in
  high difficulty as a proxy for proof of validity. BitCoinJ is an
  implementation of this mode.

http://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification

Also read:

https://en.bitnovosti.com/2018/07/06/jonas-schnelli-current-and-future-state-of-wallets/
https://github.com/bisq-network/bisq/issues/1062
http://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29

MultiBit, Bitcoin Wallet for Android, and Electrum are examples of SPV clients.


Using xpub key derivation for user account balance?

xpub is short for Extended Public Keys. Public keys, as their name suggests, are meant to be public. If the xpub is stolen, then all that will happen is that the thief will know how much money you have and public keys associated with those coins. All you lose is your privacy, no money is at risk.


What about all the coins that have been locked in wallets due to loss of keys, owners of wallets dying, etc...?

There is no way someone can tell you the exact amount of "locked" bitcoins. Even after looking into blockchain and building the system of how often bitcoins move from one wallet to another. There are many people who have bitcoins and sitting on them for many years, but still have the access and can use them anytime they want (it can be considered as lost bitcoins, but it's not). So it will be impossible to track how many bitcoins are lost "forever" by users.

Are there any solutions to lost coins or is this just a feature of the decentralized network?

There is no current solution and I'm not sure there will be one. Bitcoin wallets/storage services improve their security and adding more and more features to recover your keys, passwords, etc., but it has nothing to do with those people who lost it long time ago.


No idea what wallet site, or password(s) but has the old computer

Is there a way to find enough data to recover her BTC?

Probably not.

If she didn't make a note of her password and forgot it then she almost certainly didn't make a safe backup of her private-key or seed-phrase either. You could ask her about that though

  She is and was clueless about btc, wallets, etc

That often means people lose their BTC.

  My friend was paid out in bitcoin approx 2 years ago

Her best chance would be to find email or other correspondence relating to that event. If she can remember who "paid out" and why, maybe she can get back in touch with them and hope that they recall where the BTC were sent - they may at least have a record of the receiving address and that will help her find out whether there is still any unspent BTC associated with that address.


Will I have to create a transaction with 100 different sources (the 100 different addresses) and a single destination?

Yes.

  Will this transaction cost more than a simple one-source one-destination transaction (e.g. because it is larger)?

Yes.

However, this has nothing to do with using multiple addressses or not. Whenever you receive money in 100 transactions, it creates 100 unspent transaction outputs (coins). If you want to spend them, you need to redeem all those 100 coins. Whether they're all sent to the same address or not is completely irrelevant.

So:

  Is there a cost to having many different addresses?

No.


Easy way to compare bitcoin node block to total block, check sync status

Since you're already on the command line, try:

wget -q -O- https://blockexplorer.com/q/getblockcount; echo


Which values are GetValueIn() and GetValueOut() calculate?

But what the GetValueOut() calculate - all vout for a Tx?

Yes, it calculates the total value of all the outputs in the transaction. It also makes sure that the value is not out of range of the total supply of Bitcoin (21M).


As the final bankruptcy has not taken place, you don't know yet what you lost.  There could be some partial recovery paid to accounts.

Eventually the bankruptcy will be finalized, you'll get access to records, and you'll get the final determination of what was lost.  You'd claim your loss in that tax year, not 2013.

Edit: I see in your question you also might be wondering about paying taxes on any gains. If you have records, unfortunately you'd have to claim those as gains in the 2013 tax year.  If you have no records, you have to estimate using your best judgment.


Am I doing something wrong?

Yes. mining_proxy is used to translate from stratum to the old getwork protocol. This is useful if you want to use a mining program that does not support stratum, but you still want to get the benefits of stratum.

However, minerd supports stratum out of the box. You don't need mining_proxy.

You should remove the first and third commands.


Is It Possible to Prove Ownership of Public Key Hash without Public Key?

The simple answer is no.

A hashing algorithm is ment to be a one-way function. If it is possible to recreate the public key from the hash, this means that the hashing algorithm is broken.

However there is one aspect that you might find useful. For message signatures, bitcoin uses a custom encoding (compared to the DER encoded signature found in transactions).

Given a custom encoded message signature, the message and a public key hash, you can verify that the signature is correct. However, please note that this is because the custom encoded signature supports public key recovery. Therefore this results in the same security aspects as just supplying the public key, but with the benefit that the user does not need to specifically transfer the public key to you.

If you would like to test the custom encoded signatures, they are returned by the "signmessage" function in the bitcoin core client. They can then be verified by the "verifymessage" function, or by multiple online tools, such as this one:
https://blockexplorer.com/messages/verify


Coinbase tells me to send from electrum to my private key?

Tl;dr: what you have is

a seed-phrase for a Bitcoin wallet (where you look after your own cash)
a receiving address associated with a Coinbase account (where you let Coinbase have ownership of your cash in return for an IOU)

You don't have a private key (and you don't need one so long as you keep that seed-phrase written down somewhere safe - not on a computer)

I received 12 keywords

That is almost certainly a seed phrase, also called a recovery-phrase or backup-phrase.
Your master private key is generated from that seed phrase.
In a hierarchical deterministic (HD) wallet, that master private key is used to generate many pairs of private keys and public keys.
For the most common types of Bitcoin transaction, a public key is used to generate a bitcoin address to which money can be sent.

and a hash (starting with 17) which I always thought was my bitcoin key.

A string of around 32, 33 letters and digits starting with a "1" is an old-style of Bitcoin address that is still valid and popular. It is a Bitcoin address, not a private key.
To see some examples look at some reference pages such as

https://en.bitcoin.it/wiki/Invoice_address
https://en.bitcoin.it/wiki/Private_key
https://en.bitcoin.it/wiki/Seed_phrase

Note that the same private key can be shown to you in several different ways (encodings, display-formats).
From the above you should be able to reassure yourself that what you have is a 12-word seed-phrase for your wallet and an  unrelated bitcoin address for your Coinbase account.


Discrepancy Between Nonce for Single Block

The block presented with the second link (api.blockcypher.com/v1/btc/main/blocks/1) is not the same as the one presented with blockchain.info.

"api.blockcypher.com" says block 1 (Height=1) has a "previous block" of all zeroes:

but that is the block with Height=0, not with Height=1 !.

One could argue that "api.blockcypher.com" starts counting (oddly) on "1", but the problem is that their next block (block 2) has a "previous block" of "00000000839a8..." (correct) which in fact is not their block 1...

That is, there is a gap in their API, and the block with a "previous block"="000000000019d66..." or block with Height=1, is not accessible using block count:

"api.blockcypher.com" block 1 is really the block 0 (Height=0), and
their block 2 is the correct block 2 (Height=2), and so
the block 1 that you are trying to see is unreachable in that API (!).

That also means that Nonce=2573394689 for block 1 from blockchain.info is the correct value.


Can I safely run Tor and Armory through Tor simultaneously?

No, it's a bad idea to run bitcoin over tor if your striving for anonymity. Here is a paper detailing the vulnerability.

  While Bitcoin provides some level of anonymity (or rather pseudonymity) by encouraging the users to have any number of random-looking Bitcoin addresses, recent research shows that this level of anonymity is rather low. This encourages users to connect to the Bitcoin network through anonymizers like Tor and motivates development of default Tor functionality for popular mobile SPV clients. In this paper we show that combining Tor and Bitcoin creates an attack vector for the deterministic and stealthy man-in-the-middle attacks. A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor. In particular the attacker can link together user's transactions regardless of pseudonyms used, control which Bitcoin blocks and transactions are relayed to the user and can delay or discard user's transactions and blocks. In collusion with a powerful miner double-spending attacks become possible and a totally virtual Bitcoin reality can be created for such set of users.


Where to find the blockchain on Bitcoin ABC?

As per the documentation https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/files.md

blocks/blk000??.dat: block data (custom, 128 MiB per file); since 0.8.0

These files should be in C:/Users/(username)/AppData/Roaming/Bitcoin which is the standard app data directory.


What really happen when user moves fund between Main Account and Trading Account in HitBTC?

This is purely an internal accounting move, no keys are involved.

Their comparison to a hot/cold valid is likely just an analogy. In reality, their application layer (or some middleware) enforces some checks to make sure you can only trade values inside your trading account.

When you transfer funds between them, their internal database accounts are updated. This has nothing to do with blockchains or private keys or utxos. It's purely an internal movement.


I found a similar question here:

so I just Reprinted:

The rev*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk*.dat files which contain blocks.

Each block record consists of:

bytes: network magic (0xf9,0xbe,0xb4,0xd9)
4 bytes: size of the CBlockUndo record (LE32)
data_size bytes: CBlockUndo record
32 bytes: double-SHA256 of the serialized CBlockUndo record

A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.

A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.

A CTxInUndo record consists of:

varint: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO
varint: creating transaction's version [only when height > 0]
CompressedScript: spent UTXO's scriptPubKey
CompressedAmount: spent UTXO's nValue

Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.


What if block N were based not on N-1 but on both N-2 and N-3?

Objections that come to mind initially, I'm sure there are more:

You don't want to split the hashing power into two halves because that would make it easier for an adversary to get 51% of that halve: 25% of the total or even less if the halves are not exactly 50-50.
The idea behind Proof of Work is to concentrate as much work as possible behind one and the same chain and make that the level-to-beat by an attacker.

If you force odd transactions into odd blocks (and vice versa) then you still have 10 minutes block times for all transactions.


How is the mempool incorporated in the calculation of the block hash?

Every node in the network has a mempool. The mempool contains unconfirmed transactions. Each mempool may be slightly different as they constitute a subset of all unconfirmed transactions in the network: Some might not have been relayed to a node, so he doesn't know about them, the node owner has set a higher minTxRelayFee and filtered out some transactions with low fee, or the node owner has set a smaller data limit for his mempool.

Anyway, all of the above is also true for any miner's node. When miners are trying to find a block, they select a set of transactions to confirm from their mempool. From these transactions, they build a Merkle tree.
The Merkle tree allows the whole transaction data to be represented by only the Merkle root. This Merkle root is part of the block header.
Miners get to choose which transactions to include freely, and they can also put them in any order they want, as long as the transactions are valid. Since there are now often more transactions available for confirmation than block space, miners usually select transactions that maximize the fees that the miner can earn.

So, miners have selected some transactions and created a Merkle tree to contain them. They combine this with the other parts of the block header: Time-stamp, Reference to previous block, difficulty statement, and the nonce. The nonce is an arbitrary number, so miners can build a block candidate with all the other data and then try this candidate a lot of times by cycling through all possible values for the nonce.
Every try they put the block header into the hashing algorithm and receive a digest or hash of the data. If this hash satisfies the difficulty statement, the miner has found a new block and will relay it to the network.


Is there a good tutorial on how to use bitcoinjs exit nodes?

You can start with the included test package first. Then check the dependent projects.


I was never asked to create a password for my Bitcoin Wallet

A few things...
As a general rule do not store your seed phrase on services like iCloud or Google Drive etc. If your account is compromised by someone with malintent, your crypto will likely disappear forever.
You don't need a password and even if the app required you to make a password to login you wouldn't really need the password to access your coins. You only need your seed phrase.
You can input your seed phrase with the same bitcoin wallet program or almost any other
and gain access to your coins again. As long as you have the seed phrase, your good.
Also, I would move those coins to a new address with a new seed phrase if you value those funds.
One more thing, hardware wallets are generally your most secure option.


Any studies on minimum USD value needed on BTC to make mining worth the cost?

I don't think a study is necessary - logic should suffice.

The difficulty of the hashing "puzzle" (how many zeroes the hash must start with) is automatically calculated based on the current hashing power - ie. how many miners are trying to solve the puzzle.

The difficulty is calculated so that the average time to mine a block is always around 10 minutes. No matter how many miners are trying to solve it.

...so if the dollar-value of bitcoin goes down it will lead to:

The value of the block reward going down - so the incentive to mine drops.
Some miners will then stop mining - because it's no longer profitable for them (who goes first depends on each miners ability to compete - ie. his cost for electricity and so on compared to competing miners - but someone will quit to do something profitable instead).
The combined hashing power of all miners will go down - since there are fewer of them.
The difficulty of the puzzle will self-adjust (it will become easier) - making it more likely for each remaining miner to solve a block and get the (smaller) reward.

And balance is restored... the miners who continued mining will still be able to turn a profit in spite of a lower reward per block.

It will always be profitable for some miners to continue mining - unless of course the value of bitcoin goes all the way to zero.

The point is that whatever the total reward for "finding" a block is (block reward and fees combined) - that is how much will be invested in mining it (minus of course a small profit for the miner - but this is likely only a tiny fraction of the actual reward).

The important point is that the lower the difficulty is, the lower the security is.

If we imagine that value goes all the way down to the point where the total reward for mining a block is for example $1, someone will still be mining - but there will be so few that it will be easy to do a 51% attack: You'd be able to construct an "alternate" history for just $1 per block, so it wouldn't cost much to get the longest chain.

...but the reward for taking over the chain will also be almost nothing - so why bother :)


Can transaction inputs reference outputs of pending transactions?

If transaction Y is in block B, then it is - for purposes of deciding whether X's inputs are valid - confirmed.

As far as consensus rules are concerned, a transaction X can spend outputs from a transaction Y that is anywhere in the block chain before X. That means either Y is in an earlier block as X, or in the same block but in an earlier position.

The P2P transaction relay also supports this. It will relay transactions that spend outputs of unconfirmed transactions under some conditions. Given two interdependent unconfirmed transactions, miners can decide to put both of them in the same block, or only include the first one in a block (leaving the other one in the memory pool for inclusion in a later block).


You should check if port 8333 is open. If port is closed from internet, bitcoin client will make only 8 outgoing connections. maxconnections parameter works only for incoming connections.


Double spend problem on a delay tolerant network

As explained in the referenced paper [4] "SMAPs: Short Message Authentication
Protocols", the security issue is the delay-tolerant networking. Bitcoin already requires a minimum of 6, or better 8, blocks before a transaction is sufficiently secured. The trade off is between delaying the settlement and lowering the risk.


How do exchange sites know all user deposit transactions?

They're running full-node implementation.

  how do they detect deposit transactions when their services are not
  running?

It's blockchain, all data available for anyone, they able to fetch data from blockchain anytime.

  do they fetch blocks at every height to scan for deposits to avoid any
  missing?

There is a couple ways to get address deposits:

You can check the balance of particular address every N seconds.
You can parse a block and check if there are transactions related to particular address.


Guidelines for creating a PHP driven web app for redeeming Bitcoin coupons

I modified the open source Intersango exchange code so that it can issue and accept Bitcoin coupons.  You can view the code to see how I did it.  My code doesn't store the whole coupon code in the database, so even if a hacker gains read access to the database, they can't redeem the unclaimed coupons.

To answer your particular questions:

1) Is there a sample code for sending coins using bitcoind / PHP ?

Yes.  Here's some code that does it in a very simple way.

2) Is there a 3d party API providing such functionality (instead of using bitcoind)?

I don't know.  Maybe one of these has what you want.

3) Do MtGox and Tradehill have APIs for transfers?

Tradehill's no longer operating.  MtGox does.

4) Is captcha a must?

No.  They're annoying.  Have the code which checks the coupons take a long time to return a result, and only allow the users to check one at a time.  Then they can't brute force the coupons in reasonable time.


Create custom Transaction ID using Bitcoind raw transaction

For the details of computing a transaction ID, see How to calculate a hash of a Tx?
Basically, it is the double SHA256 hash of the raw transaction data.

SHA256 is believed to be a secure hash function, and part of what it means to be a secure hash function is that there is no reasonable way to "predict" what the hash of some input data will be, short of actually computing it.  It also means that there is no reasonable way to compute some input data whose hash will have a specified value.  So if you are trying to create a transaction whose ID is DEADBEEFCAFEBABE0123456789ABCDEFFEDCBA9876543210FACEFEEDACEDBEAD, or matches the ID of some existing transaction, sorry, you cannot (unless you figure out how to break SHA256).  But you can safely assume that nobody else can do so, either.


How to solo-mine bitcoins with bfgminer?

This is covered in the included README document.


TransactionId Not working Second Time in NBitcoin and QBitNinja?

Since i still have unspent amount in that transactionId so i used the same TransactionId this time as well.

This is incorrect. You cannot use the same transaction ID. You have to use the new transaction ID to spend new UTXO. The input was also used as change address in the transaction so you have a new UTXO associated with the same address. I will share one example below:
I create a new address in Bitcoin Core with getnewaddress command: tb1q8flc50kum4jwfvfc4vzqrd5e7kdmc8nm85vwwj
I send 0.01 testnet BTC to it from my Electrum Wallet in transaction: 9a1eab961a8421a4ac35da09de7870f573640a02f872f61de254f6345ed21532
There is only one UTXO (Unspent Transaction Output) associated with address tb1q8flc50kum4jwfvfc4vzqrd5e7kdmc8nm85vwwj right now.
I can use this transaction ID to create a new transaction in which I try to spend this 0.0005 BTC from 0.01 BTC I received.
I create a new transaction to send 0.0005 BTC to a random address with createrawtransaction command:
createrawtransaction "[{\"txid\":\"9a1eab961a8421a4ac35da09de7870f573640a02f872f61de254f6345ed21532\",\"vout\":1}]" "[{\"tb1q03dvss952khelxea5tpjwf6upv8fshnk95sj6y\":0.0005}]"

I add change address in it to receive (0.01-0.0005-Tx_Fee) and use the same address associated with the UTXO being spent (Although a new address should be used for change):
fundrawtransaction "02000000013215d25e34f654e21df672f8020a6473f57078de09da35aca421841a96ab1e9a0100000000ffffffff0150c30000000000001600147c5ac840b455af9f9b3da2c327275c0b0e985e7600000000" '{"changeAddress" : "tb1q8flc50kum4jwfvfc4vzqrd5e7kdmc8nm85vwwj"}'

Sign the transaction:
signrawtransactionwithwallet 02000000013215d25e34f654e21df672f8020a6473f57078de09da35aca421841a96ab1e9a0100000000ffffffff02637e0e00000000001600143a7f8a3edcdd64e4b138ab0401b699f59bbc1e7b50c30000000000001600147c5ac840b455af9f9b3da2c327275c0b0e985e7600000000

Broadcast the transaction:
sendrawtransaction 020000000001013215d25e34f654e21df672f8020a6473f57078de09da35aca421841a96ab1e9a0100000000ffffffff02637e0e00000000001600143a7f8a3edcdd64e4b138ab0401b699f59bbc1e7b50c30000000000001600147c5ac840b455af9f9b3da2c327275c0b0e985e760247304402203dffb9e827b95ab91cb1b42df88629b0a9222c64d277596707ec97b78392cf4b02205390bc9844e157fa9c3c8dbcce69c71c0db84af9cbdb79811ca0b8f68562bff4012102bdce2c0d9dd8337d0d18dafe145848406eaee5d024382dcae086e52868d86d7200000000

I understand the steps are not exactly the same as used in NBitcoin but the basic concepts of creating, signing and broadcasting transactions remains the same.
Let me share a rough diagram to show the things I did above:

Tx1: https://tbtc.bitaps.com/9a1eab961a8421a4ac35da09de7870f573640a02f872f61de254f6345ed21532/tb1q8flc50kum4jwfvfc4vzqrd5e7kdmc8nm85vwwj
Tx2: https://tbtc.bitaps.com/399375484659b8b1015edd752afa2ef3765adc331e8439acf14c017716d4b842/tb1q8flc50kum4jwfvfc4vzqrd5e7kdmc8nm85vwwj
We used Tx1 to spend UTXO which cannot be done twice. We received more BTC in Tx2 which can be spent using Tx2. An address can have many UTXOs associated with it.


What does the bits field represent?

First of all, we need to understand what the 'bits' field means.

Bits is in 'compact' format.  This is kind of like a floating point format, but it represents big integers rather than arbitrary real numbers.  The first byte indicates the number of bytes the represented number takes up, and the next one to three bytes give the most significant digits of the number.  If the 2nd byte has a value greater than 127 then the number is interpreted as being negative.

To convert a positive integer to 'compact' format, we:

convert the integer into base 256.
if the first (most significant) digit is greater than 127 (0x7f), prepend a zero digit
the first byte of the 'compact' format is the number of digits in the above base 256 representation, including the prepended zero if it's present
the following three bytes are the first three digits of the above representation.  If less than three digits are present, then one or more of the last bytes of the compact representation will be zero.

Example 1 - Convert 1000 to 'compact' format

For example, to represent 1000 in 'compact' format, we convert to base 256:

1000 = (0x03)*256 + (0xe8)*1

So we have a 2 digit base 256 number:

03 e8

The first digit is not greater than 0x7f, so we don't prepend a zero digit:

03 e8

Then the compact representation becomes:

02 03 e8 00

Example 2 - Convert max target to 'compact' format

The minimum difficulty has a target of 2^(256-32)-1.  Let's represent that in 'compact' format.  First we convert it to base 256:

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

That's 28 0xff digits.  The first digit is greater than 0x7f, so we prepend a zero digit:

00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Now it's 29 digits long.  hex(29) = 0x1d.  So the 'compact' representation of this is:

1d 00 ff ff

Notice we've lost a lot of 'ff' digits there.  We've only kept 2 bytes of precision, what with the size byte and the prepended zero byte using up two of the four available bytes.  If we were to convert back from 'compact' format to see what number we've actually stored, we get:

ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

which is in fact the maximum target used by Bitcoin.  This is what a difficulty of 1 sets the block hash target to be.

How is the value of the bits field calculated?

Now that we know what the bits field means, we can look at how its value is decided.  In the official client, the bits value is calculated by function GetNextWorkRequired() in src/main.cpp, which does the following:

if we're working on a block that's a multiple of 2016 (every 2 weeks)

look at the timestamps on the last block, and the block 2015 blocks before it
calculate the difference in these two timestamps
if the difference is greater than 8 weeks, set it to 8 weeks; this prevents the difficulty decreasing by more than a factor of 4
if the difference is less than half a week, set it to half a week; this prevents the difficulty increasing by more than a factor of 4
multiply the difference by the current target (ie. the current bits converted from 'compact' representation to the target it represents)
divide the result by 2 weeks
if the result is greater than the maximum target (2^(256-32)-1), set it to the maximum target
convert the result to 'compact' form, and use that as the new bits value

otherwise (we're working on a block that's NOT a multiple of 2016

if we're on testnet and it's later than 15 Feb 2012

if it's been more than 20 minutes since the last block was found

set bits to its highest possible value, 0x1d00ffff, which represents a difficulty of 1; this is the 'special-min-difficulty rule'

otherwise

set bits to the same as in the last non-special-min-difficulty rule block

otherwise (we're not on testnet, or it's before 15 Feb 2012)

set bits to the same as in the last block


Is there any benefits to a distributed computing architecture outside of cryptocurrencies?

The only systems which benefit from being distributed are ones that display the property of being "embarrassingly parallel", or some approximation of it. Tasks which do not require a significant amount of data to be transmitted between operating systems, or those which don't require a significant amount of coordination fit this description well. Typically anything like a database is poorly suited to being distributed due to the need for overall consistency, which is very difficult to achieve across a distance.

Bitcoin is the opposite of a distributed system at the node level, every participant in the system is expected to repeat the process of validation in perfect accuracy with the hundreds of thousands, or millions of previous attempts at synchronization that have happened before it. As the number of nodes increases, there is no change in the amount of computation done in either direction.

Generally speaking anything claiming to improve efficiency by using a decentralized, or distributed network should be met with skepticism, simply because this is typically an uphill battle that is taken on for other reasons despite its inefficiency, not in an attempt to gain efficiency. To exemplify this, Bitcoin would be most efficient, most usable, and most reliable if it ran on a single server, but that would largely defeat the design brief of being trust-less.


Where is bitcoin.conf location on MacOS with Bitcoin core v0.15.1

Bitcoin.conf usually arent come with it so you have to make one manually by making a file and naming it bitcoin.conf

After you made it, you can use the link below to use the configuration as template

LINK

Hope the answer above is what your looking for


Did I lost my balance by using an old wallet.dat?

Ack! You certainly could have.

When you send bitcoin, the "change" is returned to an address that you have not previously used to protect your privacy. If your wallet.dat files doesn't contain any unused addresses, a new one is generated and the corresponding private key stored back in the wallet.dat file. If this happened, and you didn't save the new file, you may not have the address the change from that transaction was returned to.

I believe that newer implementations of the bitcoin core wallet make this much less unlikely.


How difficult is it to invent a new cryptocurrency? (In regards to time, money, technical knowledge, etc.)

quick approach:-

Not that difficult , Just fork a github repo of a smart contract supporting ERC20 token starndard and deploy the contract on main net.

developer approach:-

If you want to make your own crypto currency the easiest way is to learn ethereum smart contract development , most crypto currencies present in market today are build over the top of etherum smart contract. If you have programming experience in javascript or similar languages it will be very easy to start with solidity language used to develop smart contracts.

Also learn about ERC20 token standard which is followed by crypto currencies build over top of ethereum
The ERC20 token standard describes the functions and events that an Ethereum token contract has to implement.


No, there does not such thing as initialfreecoins=10000000. However mining on regtest is not resource hungry and nearly instant. It's the only way to get coins.

To get coins on regtest you first need a address to mine those coins to. An address can be created with
 bitcoin-cli -regtest getnewaddress.

To mine and payout to this address use with <address> being the output of the first step and <nblock> the number of blocks you want to mine. A good number would be for example 101 to get 50 coins (because coins need 100 confirmations to be spendable).

bitcoin-cli -regtest generatetoaddress <nblocks> <address>

You can repeat generatetoaddress or set a higher value for <nblock> to get more coins.


Bitcoins mysteriously transferred out of my wallet?

Did someone break into my wallet?

If you were using standard bitcoin client -- then yes. If some online wallet like blockchain.info -- anything could have happened.

  Wouldn't they need my private key and my password to do that?

The only thing needed to transfer coins is private key.


Is it possible for a person's transaction to show up on the network BEFORE mine if I send bitcoins before him?

It is not clear what you mean with "show up on the network". I will assume that you mean "included in the blockchain" rather than "submitted to the network".

Transactions are spread peer to peer.

When a users sends a transaction, he transmits it to all the peers he is connected to. All these peers will then propagate it to their peers, and the recipients will repeat so again until all nodes in the network have received the transmission.

An exaggerated example

Let's imagine the following (hypothetic) situation:
A has only one peer, who in turn only has only one other peer. Let's say A is connected to the network in a very long chain of weakly connected nodes, which then at some point leads to the "well-connected network".
On the other hand C has ten peers, of which one is very well connected such as a mining pool operator.

Now, when A sends his transaction, it is transmitted to one other node in the network, then a second is notified, in the next step only a third. Obviously, it will take some time until the transaction will spread to the whole network. On the other hand, when C sends his transaction, it is immediately received by 10 other nodes. Each of those sends it to ten other nodes, the mining pool might even send it to hundreds. The network will be notified very quickly of that transaction.

We can see different propagation times, but the effect isn't that huge

According to BitcoinStats, it takes about 0.651 seconds for a transaction to be seen by 50% of the network, and about 2.761 seconds to be seen by 90% of the network.
Also, the above example is exaggerated: Usually, every node will try to connect to several nodes. However, the effect that some transactions will spread faster due to being submitted to well-connected nodes still exists. If a miner finds a block and had already received the transaction of C but not A's. C's might be included in a block before A's transaction. However, the window is pretty small, since the block interval is much bigger than the propagation time.
The effect would be especially pronounced, if A's transaction didn't include a transaction fee, or was non-standard, and therefore not propagated by all nodes.


How does the computing power of the Namecoin network compare to the Bitcoin network?

Since Namecoin started using merged mining with Bitcoin, its effective processing power increased substantially. The current difficulty is 1063443.

This is very high considering the resale value of namecoins (1 namecoin is worth 0.002 of a bitcoin) and given that the difficulty is 49% of the Bitcoin difficulty.

The Bitcoin network currently is around 16TH/s, so you'd need around 8TH/s to successfully attack the Namecoin network. That would be pretty expensive!


Which security threats in P2PKH lead to the use of P2SH?

The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.

So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 out of a set of 5 keys to spend my coins. So, the scriptPubKey that I would like everyone to use when they send coins to me is:

OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG

But each pubkey is 33 bytes and so this makes a script that is ~170 bytes, which is a bit much to encode in a QR code. And it is definitely is too much data for a human to process.

But if I use P2SH, the scriptPubKey is just 23 bytes and the sender doesn't have to worry about what exactly the redeem condition I am setting on my coins is. P2SH works like this. I take the script that I want to be my scriptPubKey and I serialize it (I'll use {} to denote serialization):

redeemScript = {OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG}
redeemScript_hash = hash160(sha256(redeemScript))

And then the scriptPubKey that the sender actually uses is:

OP_HASH160 {redeemScript_hash} OP_EQUAL

Which is just 23 bytes in total. The nice thing is that it provides a layer of abstraction. The person who is sending me coins doesn't need to know how I am keeping my coins secure. All they see is a hash of a redeemScript, but they don't know what conditions that redeemScript actually puts on redeeming the coins.

Basically, P2SH itself is not inherently more secure because the redeem script can be anything. But what it does is enable coin-receivers to easily communicate how coin-senders should send them coins, while letting the coin-receivers dictate the conditions of how/when those coins can be spent.


What does the scriptSing contain when it is decoded with RPC framework?

Bitcoin does not actually use addresses internally. Addresses are just a way for us humans to specify what scriptPubKey we want the wallet software to create. When a transaction output is spent, the address is not included anywhere because it is not needed.

Bitcoin Core's decoding RPCs will include more information than is actually present in the transaction, block, or script. This is because it can infer and display the information present in different ways.

Since an address describes a scriptPubKey, it is typically possible to take a scriptPubKey and compute an address that corresponds to it. This is not always possible because not all scriptPubKeys correspond to addresses. But usually they do, and so the decoder will show you that.

However scriptSigs do not have corresponding addresses. You cannot get a scriptSig from an address and vice versa. In fact, the idea that you send from an address is really not true; that's just a simpler way to describe things to people. It isn't how Bitcoin actually works.

The reference to the previous output is done by explicitly referencing it, not referencing some address. Every output is uniquely identified by the transaction it is included in, and its index in the array of outputs in that transaction. Bitcoin Core displays this to you as the txid and vout fields for each input.

Bitcoin really does not have wallet ids. Contrary to popular belief, addresses are not wallet ids, nor are public keys.


How to get Bittrex Commission Value from API

According to the latest Bittrex Beta documentation, there is a JSON key called "CommissionPaid", minified to "n", which would indicate how much commission was paid on a trade. From my experience, it would seem that only the new beta websocket API provides this information, which means you'd have to subscribe to that and check the feed for this value.

A comment from someone associated with the Bittrex API, at the Github link posted above, indicates that he does not believe the REST API will undergo changes, so with that, I would not expect for this key to be transferred to the REST version.


Wanted to back up blockchain to save space, now I cannot open bitcoin QT?

Delete your chainstate and blocks folder and start Bitcoin-Qt again. It will then re-sync your blockchain.


How can i trace a transaction where my bitcoin has been withdrawn from my paper wallet?

Technically you only need your bitcoin address from your paper wallet to track it.
But that would be tracking it on the bitcoin blockchain.
You can use any of the bitcoin blockchain explorers, just paste your paper bitcoin address into any of these and see which address it was sent to:
https://blockstream.info
https://mempool.space

However as you track your UTXO, you'll start seeing that it gets more difficult if it has been sent many times to different addresses.
And if you're looking to track it into real world (meat space) you have even fewer options. You can look into popular exchange addresses and see if someone deposited them there and reach out manually.


What happens if I send bitcoins to my private key instead of my actual bitcoin address?

A private key can be encoded in a number of different formats:

51 characters base58, starts with a '5'
(for example: 5JrnhhNpRNsC6xPUhLfc4yJEviuRxMcvpcB4pc1opgHTSVi64aP)
64 characters [0-9A-F] hexadecimal format,
for example: 89609C6B52AE0061FB8FFE3AF83528AC24AC637A386FE61D2822128ABE80162F
44 characters base64,
for example: iWCca1KuAGH7j/46+DUorCSsY3o4b+YdKCISir6AFi8=
52 characters base58, WIF Compressed, starts with a 'K' or 'L',
for example: L1pkidDJJbWY1HUDF3oPnXV6U7xR9L1aZ8FRs7YZfSPdh5NPzRB5

A bitcoin address, which is a hash of the public key, is 25-34 characters, typically 34 characters,
for example: 1A5QMFw4vXVwLF1zZMSvAYJStuVMcjSqAa

Maybe a bitcoin address could be encoded in some other format, but 25-34 characters of base58 is the standard.

I don't know what kind of validations are in place at bitbrothersllc, but they should easily be able to see that you entered 51, 64, 44, or 52 characters instead of the 25-34 characters that would make up a valid bitcoin address.

Contact them.  If they are legit, you'll get your funds back.  Good luck!


Fees are there because of penny-flooding attack, which is a praticular kind of denial-of-service.

Without fees you would have a situation in which an attacker can fill the memory pool with 0-costs pending transactions, which would cause a sensible service degradation.

An attacker could move its funds between addresses of its own, spamming thousands of transactions on the network without losing anything. The memory pool would grow until filled, and since miners are not able to discriminate between honest transactions and malicious transactions, this will result in no (or few) honest transactions being processed and included in the chain.

By adding a fee you are adding a cost to such attack. An attacker is no longer able to generate thousands (or more) of fake transactions at no costs.


How does the network know the legitimate chain in a double-spend attempt?

Imagine the blockchain as... a chain of blocks

The situation is:

A -> B -> C
      \-> C'

But some nodes see it as  A -> B -> C and mine over the block C

and some other see A -> B -> C' and mine over the block C'

If node sees something like this:

A -> B -> C -> D -> E...
      \-> C'-> D'-> E'...

it should select the chain with larger cumulative difficulty (longest) and forget anything about orphan chain


Is their any way to identify whether the miner is using renewable or non renewable energy for mining?

No, this is not possible. Energy sources are not part of the blockchain.


This is probably better for Money.SE as it doesn't really have anything to do with Bitcoin; it would be the same for any sort of  income.

However, my understanding of tax law with respect to gifts is roughly this:

Money, goods or services that you earn from working, business or investing are taxable income to you.
If you decide to give some of that money to someone else, that's your business; but you still earned it, and it's still your taxable income.  Giving it away doesn't change your taxes at all.  The IRS doesn't really care whether you gave it to your friend or used it to buy 300 pounds of jellybeans.
Within certain limits, the gift is not taxable income to your friend (who didn't earn it).  However, above those limits, it can be subject to gift tax.  I think beyond $13,000 per year, you have to start keeping track of such gifts; gift tax does not actually kick in until a larger number, but it counts gifts spread across several years.
The one major exception is if you give the money to a registered charitable organization.  Then you can deduct the gift from your income, again up to certain limits (usually 50% of your income).

Disclaimer: If you want tax advice, talk to a professional who's qualified to give it.  I'm not.


Using Python: create a private key of my choosing, then generate public key and address

For this very reduced case, you can take a look at https://github.com/circulosmeos/bitcoin-in-tiny-pieces

It has each operation coded for ease of understanding, isolated in a different file, but they're easy to join or to use directly from command line: for example:

$ echo 0x01 | ./bitcoin-public-from-private.py | ./bitcoin-address-from-public-key.py

And for the question:

  For instance could there be an arbitrary or infinite number of pub keys from the private key?

In principle, from a private key only one public key is derived: but this can be coded in three different Bitcoin addresses. Normally only one or two of these formats are used.

This is in the most simple case, not considering more complex cases introduced later in Bitcoin (like HD keys, etc)...


I transferred BTC from my blockchain wallet to my trading wallet using my can to address and it never showed up!

If you transferred funds to the receiving address for your trading account, and the transaction is included/confirmed in a block on the blockchain, but not showing up in your trading account, then you need to contact your trading platform.
A few points to remember here:
1: Once a transaction has been included in a block, it CANNOT be cancelled, voided, or "called back." The only way you could get that bitcoin back is if you have the recipient send it back to you in a new transaction.
2: While most reputable exchanges use separate wallets for each client to deposit to & have servers monitoring for incoming transfers, there is always the possibility of a "glitch" or "server goof." As soon as any deposit to your exchange wallet has more that 3 confirmations on the blockchain, if the exchange hasn't updated your transaction, CONTACT THEM, it could be an honest mistake & if so, they'll be more than happy to correct it for you.
3: All responsibility for making sure your bitcoin transactions go to the right place rests on YOU. Since bitcoin is a decentralized platform, there's no central bank/government you can contact if you make a mistake. Therefore, you should always verify ALL of the information (destination address...read at least the first & last 5 digits, coin amount, and coin type [make sure you don't send BTC to a BCH or BSV wallet]) at least twice BEFORE you confirm sending a transaction.


How do I move money from one address to another on the same wallet?

Create a new address and send your entire balance to that new address.


0 fee transactions - possible that they never confirm?

Yes. It is possible that a transaction is never confirmed, even if it does pay a fee. Transactions that pay more fee take precedence, and after a while your old unconfirmed transaction will drop out of the mempool.

Edit: This answer originally stated that older transactions get prioritized, but that behavior is no longer active on the network.


How to verify if it's Segwit Transaction or not?

A transaction is a segwit tx if at least one of the inputs contain a witness. Or if you are inspecting the raw tx then you check the 5th byte (the input count) and if it is 0x00 then it is a segwit tx.

Example:
tx1

  02000000055f4e5315ffe854e75db92f8dda952a8db2f63b37838fca4c32bd4bb692fe7ea2000000006a47304402200ab62a9d1858dceeaa2101cda3f31b7bae60471c0355c54a6eae48f723555806022010d2aad6362a8c56ed66b0670ff84175f534f4f0995f8724a9b2a5fc89a2a4b4012102c424c2670a7aade9cf867576064013d02cc7669c418968993e73e6b25fc122bcfeffffff80cb1bfcde0f309490c717eca07f1353f121fb13e105...

is not a segwit tx because the input count is 0x05 = 5

tx2

  0100000000010106325bac2f2e7ca67fa46c8304fb3b747e5578df1eef0394349ce2cdd744f7f10100000000ffffffff02db355202000000001976a91489ea1263056ac068adba4844efb376a3a19635ad88ac43b72f07000000002...

is a segwit tx because the input count is 0x00 = 0

Also:

Transactions spending P2PKH inputs (address starting with 1) cannot
be segwit.
Transactions spending P2SH inputs will be segwit if they are nested
P2SH, otherwise not.
Transactions spending P2WPKH or P2WSH (starting with bc1) will be
segwit.

In your example:

  legacy -> P2SH

This cannot be a segwit tx because it spends inputs from a legacy address

  P2SH -> legacy

This can be a segwit tx if the address is P2SH-P2WPKH or P2SH-P2WSH (nested segwit into P2SH). You wouldn't know if it is nested if it's not your's unless someone has already spent from it (in which case you inspect the spending tx).

  bech32 -> legacy

This is always a segwit tx


How does Ripple decide on the exchange rate between different currencies?

Since Ripple has an integrated exchange, I guess it simply places market orders in its order book, trying to get the best overall price.

You find the order book in Advanced/Trade, if you want to try manually.


This error occurs when a block that was written to disk is corrupted. This could be due to hardware failure or just simply random chance. Since the corrupted block for you occurred early on, the easiest way to fix this issue is to simply delete the blockchain and redownload it. To do that, just delete the blocks/ and chainstate/ folders inside of the datadir (the directory that contains the debug.log file). Then start Bitcoin Core.


Find who all donated/transacted to/with a particular website/person

There is no way to achieve what you want effortlessly. I am not aware of any public free site that does what you want and any service that does this kind of work would not be cheap.

Short of sorting through the blockchain looking for transactions related to the address of the known person A and then trying to correlate other addresses that transacted with known person A address from other web sources could you begin to try do what you wish to accomplish.
For instance wikileaks donation addresses are public, you can search for if person A address paid the wikileaks address but thats a lot of either manual work, coding your own scripts, or paying someone else for the work.


How can i set up CPU mining on bfgminer?

You can run a miner on a CPU, you just won't generate any measurable revenue. But as an experiment, it's certainly possible to do. I run cgminer on a CPU as an integration test for one of my node.js modules.

This is a rough outline of the steps you can go through to install an older, CPU-supported version of cgminer on your computer: https://github.com/hashware/node-cgminer-api/blob/master/.travis.yml#L11-L24


You can use a node in pruning mode. In Pruning mode, the node will delete the blockchain data that it no longer needs. It is still a full node as it still has to download all blocks and transactions and then verifies them. But it just doesn't store the entire blockchain.


What if somebody sees the password as the transaction is being relayed around, and makes a new version that transfers your bitcoins to them? If they have better network integration/a higher bandwidth connection, then their version might be able to overtake yours.


Legal issues / banking issues selling Bitcoins to people OTC?

Note: This is a US-centric answer. Other countries may differ. I'll add other countries as people leave comments.

There is an arbitrary limit of $1,000 per person per day that triggers the necessity to register as a money service business. Stay under that FinCEN is unlikely to care about you, although you still may legally need to register for smaller transactions.
As long as a single transaction does not exceed $10,000, your financial institution should not file a Suspicious Activity Report.
You are best opening an account at an institution separate from your personal, general use accounts.
Try to keep cash liquid. Buy local, sell local. If you've got enough volume, use money orders to get fiat into your exchange of choice. It'll cut into your profits a little, but it reduces the number of parties privy to your transactions. Do not fraudulently fill out money orders.
Keep solid books that include the fiat price at the time you purchased your bitcoin and the price of sale. This will help you calculate capital gains taxes.
Pay taxes. Assuming you're in the US, this means paying taxes quarterly instead of yearly, unless you expect to owe less than $1,000.
If you do register with FinCEN, please document the process and broadcast here, on BitcoinTalk, and on /r/bitcoin.
Be truthful, upfront, and, most of all, careful. When in doubt, talk to a lawyer.


How can a seed generate the wrong addresses?

Once you use a BTC receiving address once, any good wallet will not display the same address again; they'll display the next address in the chain (since your seed derives to a large chain of different addresses). The coins are not lost, your wallet balance should still be there, and the wallet will still track the old address, it just won't display the old addresses by default to discourage reuse of the old address.


API for large number of queries to different addresses every few minutes

You can use a self-hosted (but low-burden!) instance of Esplora.
Blockstream is also exposing an instance for free (at the moment) at blockstream.info.
Disclaimer: if you take part of Bitcoin as an economic actor (as an application providing account balances may imply), you should really consider using your own source of truth and self-host the instance. It's just a docker to start and an nginx reverse proxy to set up after all :-).


How are transactions verified to ensure only the eligible person can spend a Bitcoin balance?

Read about Public-key cryptography and Digital signature.

For bitcoins you need the private key to spend (by signing) the coins that were "sent" to the address associated with a public key.


what if a coin is spendable by multiple keys?

Depends on the wallet. To recognise the transaction at all, their wallet would have to have the script / multisig address in it too. They'd have to have done that themselves, you can't generally trick someone because their wallet simply wouldn't see the transaction at all.


Bitcoin-cli how to get balance of a wallet on different node?

You cannot because Bitcoin Core does not store such information. Bitcoin Core does not store all information for all addresses, it only stores information for its own addresses and the lower level information needed for verifying transactions (addresses are a higher level abstraction). There are no commands that allow you to get the balances or transactions for a given address not in the Bitcoin Core wallet because such information is not available.


How to compile Bitcoin-Qt as an .exe on Ubuntu?

.exe files are for windows only. Linux systems do not use the same file extension or file type as windows. I assume you just want to create a Linux binary that can be used on all systems without installing all dependencies. To do that, you can use Bitcoin Core's depends system. Instructions are here: https://github.com/bitcoin/bitcoin/tree/master/depends.

Basically, all you need to do is (starting from the source root directory):

cd depends
make
cd ..
./configure --prefix=`pwd`/depends/x86_64-linux-gnu # Actually check what folder is created in depends after you built the dependencies and use that instead
make

Once you do that, the binaries that are produced can be moved to and used on any linux system. The binaries are located at (from the source root dir) src/bitcoind, src/qt/bitcoin-qt, src/bitcoin-cli, and src/bitcoin-tx


What is 42Coin? Why it is highly priced?

A new crypto-coin, scrypt based, which produces blocks every 42 seconds (each of which yield just 42 millionths of the currency, except for every 420th which yields x10) and for which there will be no more than 42 coins in existence. Yes, that's right, only 42 "42coins" will ever exist! That takes Bitcoin's hard limit of 21 million to the extreme, of course.

For what I've read, it's a half-joke based off the novel "The Hitchhiker's guide to the Galaxy", wherein it's stated that number 42 is the answer to the "ultimate question about God, life, the Universe and everything else" - such a question that we humans are just too dumb to fully understand, much less grasp the implications of the answer :)

Official page

Official forum, with links to pools

What amazes me is how a coin with no virtually no use appart from speculation has commanded such a high prize - it's HUNDREDS of times more valuable than a bitcoin itself! And yet, according to coinwarz, it's not all that profitable (probably because of the block's ultra-low yield).


Verifying a legitimate version of bitaddress.org on Windows

1) Google how to verify a PGP signature

2) Import author's PGP sig (from the main Web site), use procedure from 1) to verify contents of
https://www.bitaddress.org/CHANGELOG.txt.asc (and obtain SHA256 sum of the latest release, although you can get that from Github as well)

(If you trust Github and want to use an offline copy, you could skip 1) and 2) and just get the latest release from Github)

3) Download the latest release, unzip and calculate SHA256 sum of the main (bitaddress.org.htm) HTML file, compare with SHA256 sum in the URL or downloaded CHANGES.txt.asc file:
sha256sum.exe bitaddress.org.html
dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194  bitaddress.org.htm

If you skipped step 2), you can perform it in step 3 using the downloaded ZIP archive.
For checksum, use a utility you want (or two, in case you don't trust one). One example:
http://www.labtestproject.com/files/win/sha256sum/sha256sum.exe


If you have a fully downloaded blockchain in your local machine, you can parse the raw database with this script.

Then you can find in output text files transactions with TX from hash equal to 64 zeros, there is the coinbase transactions.

Each of this TX has outputs with Value fields. The sum of this Values is the mining reward that you trying to find.


How to create ECPoint from raw private key

A raw private key is not on the elliptic curve, so there will be no ECPoint.  It is a random number as described here.


Modifying the last block in a blockchain

It's true, you can have two different valid blocks (with different hashes) that both refer to the same previous block.  Call them A and B.  Then there are effectively two different branches of the block chain (so it's really a tree rather than a chain).  In such a case, each node must make their own decision as to which one to accept.  If both are at the end of the block chain, usually each node will choose the one they saw first.

In particular, a miner must decide which of A or B to use as the previous block hash in a new block.  Let's say the next winning miner chose A and mined a new block C.  Then future miners will prefer to mine on top of C instead of B, since the branch ending in C (which contains A) is longer (has more total proof-of-work) than the one that ends in B.  In the long run, the branch containing A will probably be considered as the "true" blockchain.  B becomes an orphan block and is disregarded.

If B contained transactions which A did not, and they are otherwise valid, those transactions can be included in C or some later block in the dominant branch, so they are not lost.


How does Bitcoin avoid splitting into multiple p2p networks?

As long as everyone follows the same rules, mining is convergent, because the expected interval of ten minutes allows every full node to catch up to the current state of the network.

Separate p2p networks (altcoins) derive from a different set of rules, where one of the rules is the Genesis block of the blockchain. Since their Genesis block is different and each block refers to their next ancestor until the Genesis block is reached, blocks found on a different chain are not valid for a chain with another Genesis block. They, and their ancestors are not a valid part of that chain.

As Pieter points out below,  some of the nodes' IP addresses are hard coded,  which allows new nodes to discover their first Bitcoin peers.

If the rules were the same, but two networks separately extended the chain, the heaviest chain would prevail when they reconnect. The other (lighter) chain would go stale and would not be continued. All the transactions that were previously confirmed in the network of the lighter chain would become unconfirmed and valid for mining as long as the UTXO they are spending are still unspent on the heavier chain. The process of mending a chain fork by resolving it to the benefit of the heavier chain tip is called a "chain reorganization".

Heavier and lighter here refers to the chain with the most proof of work. As long as both chain tips have the same difficulty, this would simplify to the longer chain. If the chains have different difficulties (because the separate chain tips both passed a difficulty reset), we actually need to compare the aggregated proof of work.


How can I recover a blockchain.info wallet from a 17 word phrase?

Blockchain.info's legacy wallet phrase decryption is here:

https://blockchain.info/wallet/forgot-password


Where does this pattern in the feerate distribution per block originate from?

1) Is this known behavior of an algorithm that creates block templates?

Yes. This is behavior that is present in Bitcoin Core.

Bitcoin Core bundles transactions into "packages" of one or more transactions. Each package consists of an unconfirmed transaction and its children (if any) to cover the case of Child-Pays-For-Parent. The transaction fee rate is calculated for the entire package (total fees paid by the transactions in the package divided by size of the package).

When transactions are selected, it's really the packages that are selected. Because the packages are put inside the block in the order of package fee rate, you will sometimes get a few low fee rate transactions followed by a really high fee rate transaction because they were all part of the same transaction and the high fee rate transaction was a child that paid for it's parent(s).

This is called "ancestor fee rate ordering".

  2) What motivation is there behind this feature. Is it a bug?

It is neither a feature nor a bug, it is just a quirk of how the transaction selection works.

See also: https://bitcointalk.org/index.php?topic=2058831.0


Disclaimer: IANAL, this is not legal advice, the following are some lines of thought that I've seen on the matter that seem plausible to me:

The original client was published under MIT License. The whitepaper was packaged with the original client. The license statement explicitly covers the "included documentation". It seems plausible that the whitepaper therefore was published under MIT license.
Just mentioning bitcoin.org on the whitepaper does not transfer the copyright. Transferring copyrights is a rather involved procedure, and generally copyrights always remain exclusively with the actual creator. The inclusion of the URL in the document's header could potentially be interpreted as consent to be published there. I would expect 1. and 2. to be subject of the lawsuit.
I don't have any special insights why the copyright claim would be pursued in England. Potentially, the laws are favorable to the endeavor, or it's simply due to the claimant residing there.
If someone were to establish themselves as the copyright holder, they could potentially deny some parties from publishing it or use the copyright to legally pursue some parties. More likely, it would be used as evidence to cast the claimant as the creator of Bitcoin in the eye of the public, or as means to enforce patent claims.
I'm not aware of any special statements by Satoshi Nakamoto regarding the status of the Whitepaper.

Earlier, a cease-and-desist notice was sent to Square (among others) on behalf of Craig Wright for hosting a copy of the Bitcoin whitepaper. The Crypto Open Patent Alliance (COPA) responded in February 2021 on behalf of Square, requesting that the copyright claimant substantiate the basis of the claim. After no response was received, COPA announced filing a lawsuit alleging that CW in fact does not hold the copyright in April. I am optimistic that this lawsuit will clear up the matter.


this is pretty good article calculating how many XRPs are floating on the market

http://www.thebitcointrader.com/2013/05/ripple-is-now-tsunami.html


Bitcoin Core does not support signing scripts with CLTV instructions.

It only supports:

P2PK
P2PKH
k-of-n multisig
P2WSH wrapped versions of the above
P2WPKH
P2SH wrapped versions of the above

If you want to sign anything else, you'll need to implement your own signing logic.

The error you're seeing is due to the spending transaction not having the nLockTime field set. In general, CLTV works indirectly:

A CLTV output puts a requirement on the spending transaction to have an nLockTime field larger than the time specified by the CLTV instruction.
A transaction with a nLockTime field can only be confirmed when the blockchain time is after the value in that field (this is even the case when no CLTV is present).

But regardless, even if you did have a correct nLockTime field, signrawtransaction would still not know how to sign for that script.


How can I convert a bitcoin public key to a bitcoin address?

There is a step-by-step tutorial on the Bitcoin Wiki for converting Keys.

For testing there is a very good website, where you can put in a private or public key and its show you the result of any step: http://gobittest.appspot.com/Address

If you dont want to do those things on your own you could use Bitcore, a JavaScript API for Bitcoin. For a pure PHP Libary there are some custom user projects on github, but I didn't tested any of them.


What data structure should I use to model a Blockchain

First, a blockchain is it's own data structure.  It's best to think of it as one.  It represents a way to organize data in which desirable properties are gained.  However, that still does not explain how to hold one in memory/storage.

In Bitcoin, the blockchain is stored on disk (not memory) using leveldb.  This is a key/value database where the keys are the block hashes and the values are the blocks.

For an in-memory equivalent, a hash map is what you are looking for.  This is a data structure where the key is a hash of the contents (such as a block header).  From there, the header's Merkel root would point to another hash map of transactions arranged in a Merkle tree (as per the protocol).

However, an in-memory solution (which seems to be what you are after) is a terrible solution for a blockchain.  The data simply grows too quickly.  You will want to store the data to disk and have a fast way to query it.  This is why Bitcoin uses an existing database such as leveldb.


Does the Bitcoin client not record original signature data per connection?

The signature covers everything except the signature itself.  Since the signature and public key make up the input script for the most common payment type (pay-to-pubkey-hash), the input script is not part of the signed data.  This means the input script can be modified and not break the signed transaction as long as the new input script is equivalent to the original input script.  The recent attack did this by changing one of the script opcodes to an equivalent opcode.  So the new script was valid and performed the same function.  But since the opcode was changed, the transaction hash was different.

Once a transaction is part of a block, the transaction hash cannot be changed since it is now included in the Merkle tree for the block.  So the attack window is only from the time the transaction is created until a miner includes it in a block.  During this window, a modified transaction can be broadcast and it is a race to see which one makes it into the block.  The one that loses will never be confirmed since it spends inputs that are already spent.  No matter which one wins, the coins are sent to the proper destination.

The problem for Mt Gox (and others) is they track a transaction based on its transaction ID.  If the modified transaction wins and gets included in a block, the original transaction will be discarded.  This then led Mt Gox to think the money was not paid (since the transaction ID was not in the block chain) and they would create a new transaction to pay the money again.


Two if's before sending an inventory message

I don't see any reason for the second if statement, either. I'm not speaking from any form of authority here, but it looks like a (tiny) efficiency bug to me.

The second if statement has been around since the first commit. The first if statement was inserted about a year later when "trickling" of tx inv messages was added, presumably to check the set membership earlier to avoid running through the trickling logic when it's not necessary. I'd guess that the removal of the second if was simply overlooked.


Do web wallets keep customer accounts isolated?

There are different kinds of web wallets. Some are more like pieces of software that you re-download every visit, but you still actually own the private keys (re-downloading is still a risk, mind you). But in this case it looks like you're talking about an exchange or other web wallet where you don't actually own the coins anymore (i.e. they have the private key). Yes, in that case it's normal that coins are not isolated anymore. And yes, that is extremely dangerous and has gone wrong many times before.

In general try to avoid web wallets and if you really need to use for example an exchange, try to move out the Bitcoins as soon as you can, to minimize your exposure to this risk. If you're actually actively trading on such an exchange, then you don't really have a choice and simply have to accept the risk of losing all your coins one day.


Do wallets always require a private key to spend coins?

Yes, all wallets have always used private keys. They're what prevents other people from simply going and spending your money, they're used to make the authorisation signatures in a bitcoin transaction. Your best bet is to just use Bitcoin Core to load the wallet.dat file rather than importing it into a third party service.

  all this to say that my old bitcoin qt wallet never asked me for my private key

The private keys are part of the wallet.dat file and are never user facing in Bitcoin Core.


Are Micropayment channels still subject to malleability after BIP65?

There are a variety of different ways to construct a micropayment channel, but there are two designs that I think are particularly relevant to your question about "simple, one-directional, micropayment channels":

Spillman-style micropayment channels: this was a commonly-described micropayment channel design prior to BIP65 (OP_CHECKLOCKTIMEVERIFY, CLTV).  Spillman-style channels were first described by Jeremy Spillman in April 2013 and implemented in the BitcoinJ library in 2013.
CLTV-style micropayment channels: this is a new way to construct a payment channel that became possible when CLTV became enforced in mid-December 2015.  CLTV-style channels were described by BIP65 author Peter Todd as part of that BIP and implemented in two1-python in February 2016.

The following two sections describe how malleability relates to those two different types of micropayment channels.

Malleability in Spillman-style micropayment channels

BIP65 does not change how malleability affects Spillman-style micropayment channels, so the following description was true before BIP65 became enforced as well as now (at least for transactions which do not use segwit).

A Spillman-style micropayment channel is constructed using the following sequence of events between the Merchant (who is receiving the funds) and the Customer (who is spending the funds):

The Merchant gives his public key to the customer.
The Customer uses his public key and the Merchant's public key to construct a multisig P2SH address[1] that will require signatures from both the Merchant and the Customer to spend any funds paid to that address.
The Customer generates (but does not transmit) a transaction that pays the multisig P2SH address.
The Customer generates a second transaction that spends the first transaction back to one of the Customer's addresses, gives this transaction a locktime (so it can't be added to the blockchain until a certain time), and signs this transaction.
The Customer gives this second transaction to the Merchant (without giving him the first transaction), and the Merchant signs it and returns the signed transaction to the Customer.
Now the Customer will be able to use this second transaction, called the refund transaction, to claim a refund if the Merchant doesn't do anything by the time the locktime is reached.
With a backup refund assured, the Customer broadcasts the first transaction (called the deposit transaction) so it gets added to the blockchain.
Now the Customer can sign alternatives (called payment transactions) to the refund transaction which have no locktime, and so can be added to the blockchain immediately except for the fact that they also require the merchant's signature.  By giving those to the Merchant, who can co-sign them (without returning them to the Customer), the Merchant can be assured that he can add them to the blockchain at a point earlier than when the refund transaction becomes valid.

The problem with malleability occurs in the seventh step above, when the deposit transaction is broadcast.  If the transaction that gets added to the blockchain isn't byte-for-byte identical to the refund transaction which the Merchant signed in the fifth step, then the refund transaction is no longer valid because it attempts to spend a transaction with at different txid than the deposit transaction.

The Merchant can still voluntarily work with the Customer to return the Customer's money, but this means we don't have the trustless-style micropayment channels that we want.

A note on segregated witness (segwit): because segwit eliminates the type of malleability which would allow someone to change the txid of the deposit transaction without the Customer's permission, transactions that use segwit can safely use Spillman-style micropayment channels without risk of malleability-caused problems.  As of this writing, segwit is not implemented on mainnet, but I expect it will be sooner or later, so I'm describing this here for future readers of this answer.  Note that segwit is an optional feature that the Customer would already have to be using in order to eliminate malleability in this case, so activation of segwit by itself does not automatically eliminate malleability in Spillman-style channels.

[1] Bare multisig (multisig without a P2SH address) may also be used.

Malleability in CLTV-style micropayment channels

A CLTV-style micropayment channel is constructed using the following sequence of events between the Merchant and the Customer.  These steps will be identical both before and after segwit is activated.

The Merchant gives his public key to the Customer.
The Customer uses his public key and the Merchant's public key to construct a P2SH address that will require either of the following sets of conditions to be satisfied:

Both the Merchant and Customer sign any transaction that spends from this P2SH address.
Just the Customer signs any transaction that spends from this P2SH---but those spending transactions must have a locktime greater than the refund time.

The Customer generates and immediately broadcasts the deposit transaction.  The Customer is assured their ability to generate a refund transaction on demand by Condition 2.2 above.
Now the Customer can use Condition 2.1 above to half-sign (sign 1-of-2 required signatures) payment transactions that pay the Merchant.  The Merchant can generate the second signature (without providing it to the Customer) and be assured that he can broadcast the final payment transaction before the Customer can add a refund transaction to the blockchain that was generated under the terms of Condition 2.2.

This process eliminates the concerns with malleability in CLTV-style micropayment channels, although it does not eliminate the malleability itself.  Because the Customer can generate the refund transaction at any time per Condition 2.2 above, he doesn't need to pre-commit to a particular txid; he can wait until the deposit transaction has been added to the blockchain and its txid made nearly immutable before generating the refund transaction.

If, despite waiting for multiple confirmations, malleability happens anyway, the Customer can always generate and sign a new refund transaction using his private key.  That's because all that is necessary, according to Condition 2.2 in the P2SH address, is a signature from the authorized key plus a locktime past a certain date.

The Merchant can be affected by malleability if the deposit transaction txid changes after he has accepted any payments.  For this reason, it is best for the Merchant to wait for the deposit transaction to receive at least one confirmation before the Merchant accepts any payment transactions (waiting for more confirmations will provide more security and is recommended for high values).  Since the Merchant should be waiting for the deposit transaction to receive confirmation any way in order to prevent the Customer from double-spending it (which is also the case in Spillman-style channels), this source of malleability doesn't significantly affect the security model.

Conclusion

BIP65 did not fix malleability for older Spillman-style channels, but it did make possible CLTV-style payment channels that are not adversely affected by transaction malleability.  Segwit will also fix malleability for Spillman-style channels when all inputs in the deposit transaction are spending from segwit outputs.