How is a locking script reliably detected as a P2PKH script? I've taken this example from a p2pkh guide:
1976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac

This is broken down into:
19 - byte length of the following unlocking script
76 - OP_DUP: Duplicates the top stack item.
a9 - OP_HASH160: The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
14 - (20 bytes) length of the following public key hash
5fb0e9755a3424efd2ba0587d20b1e98ee29814a - public key hash of funds receiver
88 - OP_EQUALVERIFY: Returns 1 if the inputs are exactly equal, 0 otherwise. Then runs OP_VERIFY which fails and marks the transaction as invalid of the top stack value is false
ac - OP_CHECKSIG: The entire transaction's outputs, inputs, and script are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise

How does Bitcoin determine that 0x14 is the length of the following public key hash, rather than interpreting this byte as an opcode with the value 0x14 (20 decimal)? Is 0x14 special and will never be assigned to any opcode? I don't see any special handling of this value in the CScript::HasValidOps() and GetScriptOp() routines here.
Is there a magic marker to detect P2PKH scripts?

The secret is that it is being interpreted as an opcode.
Opcodes 0x01 through 0x4b (decimal 1 to 75) are opcodes that specify the length of the data being pushed after them, as their own numerical value. That is to say, 0x01 means it is followed by 1 byte of data, 0x02 means 2 bytes, and so on.
This lets you push up to 75 bytes of data using a single op code to specify the length.
Additionally, we also have 0x4c, 0x4d, and 0x4e. These specify:
0x4c - The next byte specifies the length of the data
0x4d - The next two bytes specify the length of the data in little endian order
0x4e - The next four bytes specify the length of the data in little endian order
Between these opcodes, you can push up to 4294967296 bytes of data via 0x4e. Unfortunately, you'll run out of block space a little bit before that, so I would advise against it.


Understanding Bitcoin protocol (through practice) OK, firstly, Ken Sheriff (the guy who mined Bitcoin using pencil and paper) has posted some fantastic Bitcoin articles on his blog.

In "Using Bitcoins the Hard Way" he writes (emphasis added):

  It turns out that actually using the Bitcoin protocol is harder than I
  expected. As you will see, the protocol is a bit of a jumble: it uses
  big-endian numbers, little-endian numbers, fixed-length numbers,
  variable-length numbers, custom encodings, DER encoding, and a variety
  of cryptographic algorithms, seemingly arbitrarily. As a result,
  there's a lot of annoying manipulation to get data into the right
  format.

  The second complication with using the protocol directly is that being
  cryptographic, it is very unforgiving. If you get one byte wrong, the
  transaction is rejected with no clue as to where the problem is.

  The final difficulty I encountered is that the process of signing a
  transaction is much more difficult than necessary, with a lot of
  details that need to be correct. In particular, the version of a
  transaction that gets signed is very different from the version that
  actually gets used.

Obviously working through Ken's Python files helps to understand the varying instances of appending bytes, changing endianness and the various other complicated procedures used for sending a transaction in raw hex. Likewise, the following are useful:

Protocol Specification @ Bitcoin Wiki
Graphical Address Generator @ RoyalFork
Ken Sheriff's Python code used in association with this post

My question: how does one go about learning the Bitcoin protocol by practising with the Testnet? (What resources are recommended to help formulate a raw transaction to send over the Bitcoin (Testnet) network?)

Bitcoin protocol is VERY simple. You haven't to read tons of manuals and study for years.

My point of view is (answrering your question) :

Write down on the piece of paper what you want to do.
Take your preferrable programming language (C++/Python/Delphi/Java/whatever)
Use internet sources only as referal information. Do not copy-paste
large pieces

Of course,

USE TESTNET FOR EXPERIMENTS! NOT THE MAIN NETWORK!


Derivation of parent private key from non-hardened child Quote from BIP 32:

  One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it).

How is this done?

First we must understand how BIP 32 derives non-hardened private and public keys.
From BIP 32, deriving a child private key from an extended parent private key:

let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar))) || ser32(i)).
Split I into two 32-byte sequences, IL and IR.
The returned child key Ki is parse256(IL) + kpar (mod n).

The private key is thus the parent private key plus the first 256 bits of the HMAC-SHA512 function where the key is the chaincode of the parent private key and the hashed data is the concatenation of the serialization of the public key that corresponds to the extended private key and the child key index. The important thing here to note is that the HMAC-SHA512 hash is a hash of the public key, not the private key.
From BIP 32, deriving a child public key from an extended parent public key:

let I = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i)).
Split I into two 32-byte sequences, IL and IR.
The returned child key Ki is point(parse256(IL)) + Kpar.

The child public key is the parent public key added with the public key generated from the first 256 bits of the HMAC-SHA512 function where the key is the chaincode of the parent key and data is the concatenation of the parent public key with the index of the child public key.
Notice how when deriving the child private key and the child public key you are actually hashing the same thing? You are performing the HMAC-SHA512 function with the same key (the chaincode of the parent keys) and the same data (the concatenation of the parent public key and the index of the child key). The first 256 bits of that hash become a private key of sorts, and that private key is added to the master private key to become the actual child private key. Its public key is calculated and added with the parent public key to become the child public key.
So to get the master private key, all we need to do is take the child private key that we now have, and subtract from it the private key produced by the HMAC-SHA512 function. To do that, we need three things, the chaincode, the parent public key, and the child key index.
The chaincode and parent public key come from the extended parent public key (xpub) as it encodes both the chaincode and the public key in it.
The child key index can be trivially found by deriving child public keys from the parent public key until we get the public key which corresponds to the child private key that we have and save the key index.
With these three things, we can perform the HMAC-SHA512 function and get the 512 bit hash. Now we can take the child private key and subtract from it the integer that is the first 256 bits of the hash we just generated. Our result is the parent private key. Combine that with the chaincode that we retrieved from the extended parent public key and we have ourselves the extended parent private key.

This technique only applies to non-hardened derivation. Hardened derivation protects against this because it generates the child private key by hashing the parent private key. However this also means that you cannot generate the child public key from the parent public key.


What is stopping me from modifying the mempool of my node (may it be PoS or PoW)? I have been trying to wrap my head around some core concepts of how a blockchain works and something has been bothering me for a while.

Let's consider a case where I am running a full node of a blockchain (either PoW or PoS chain). Now I am aware that a transaction relayed to my node is verified before it gets added to my node's mempool and again when it has to be added to a block. Now, let's assume that I am going to be the next block winner (I know that it is highly unpredictable), my question is as simple as, what is stopping me from taking out a transaction from the mempool (preferably one with a high amount), modifying it's vout (for e.g. replacing it with my scriptPubKey and keeping the vin intact), and accepting it in my block?

Transaction signing process involves signing the hash of the entire transaction data as a message in the ECDSA signature. So, if you modify the transaction outputs or any other data then it will render the signature invalid. If you include this transaction in the block, mine it and then relay that block, the other full nodes will see that a transaction included in the block is invalid (since it has invalid signature) and reject the block. So you will lose the block reward even after spending huge amount of electricity and compute costs to mine it.

However, having said that there can be transactions that can be signed with SINGLE or NONE sighash flags. The SINGLE flag commits to only one output, while the NONE flag commits to none of the outputs. If those flags are set while signing the transaction, then the miner can modify other outputs.


2 transaction in same address - Please help Sent my  btc address 3 days ago for a payment to one of my customer  he didnt respond or paid . next day i provided the  same address to my another customer for a payment which he sent. Now today i received an email from my 1st customer that he paid the amount to same address that i provided 3 days ago . Please anyone here who can help me to recover the funds . I will lose my job & anyone here who is kind enough to help to simple tips .

https://www.blockchain.com/btc/address/15iga5K4hLMjDFox24mvjjuak2g3cKVtMK

The address you linked has received two payments, if you control the private keys for that address then you have nothing to worry about, those coins are in your control.

Generally, it is not best practices to reuse an address, as it is very bad for your privacy (and, potentially the privacy of your customers). However, in terms of being able to spend the coins later, there is no technical issue with receiving more than one payment to an address.

You should be able to spend the two UTXOs as normal.


Bitcoin price speculation resources Where could I discuss Bitcoin price speculation, and calculating fair spot and future price.

In general for stackexchange sites, the factors for here and now would be "too localized" I think.

So I will try to broaden it. Bitcoin price - being a deflationary currency with a known max number of coins that haven't been mined or minted yet - seems to be functioning like futures converging to a spot price.

The variable factors being perceived difficulty in mining versus advances in hardware to allow mining, if you look at the difficulty charts and their correlation to price, so far.

I think with just these two factors it will be possible to calculate theoretical prices, independent of the buy/sell bidder's market.

Does anyone have any resources on this, or perhaps a better place to discuss this

The Speculation board on the BitcoinTalk forum is nonstop speculation.  That would probably be the best place to share your theories and analysis and to collaborate. Enjoy!.

There is a fair amount of discussion that falls under the category of speculation that also occurs on the #bitcoin-otc IRC channel.

And /r/bitcoin on Reddit seems to get its share of "OMG $30 Soon!" posts.


Transaction with unparsed input address ? What does it means? I just see this transaction which is special : one of input address is spending a valid amount… But why is it unparsed ? Why no ScriptSig while stil being valid ?

Also what’s the purpose ?

The output being spent is a native segwit output. If you look at the transaction that created it, you get 0014644a61cf83439e53b5dd413bec63c98c9e39c107 for the lock script, which is a native segwit p2wpkh output.

Spending a purely segwit output requires no value to be set for the scriptSig (unlike for a p2sh-p2wpkh).

The address is shown as unparsed as Insight has not been updated to recognize bech32 addresses.


How to Retrieve BTC without syncing wallet I bought approximately 1 BTC is 2013. I deposited this BTC with a wallet, but I did not keep the wallet in sync. I recently opened the wallet and it says I have 0.0 BTC, and that I have approximately 60+ weeks of syncing in order to bring my wallet up to speed. My question are as follow:

1.) how can I verify that I still own this BTC?
2.) How can I transfer the BTC to a new wallet without syncing my current wallet?

I am a noob  to BTC, any help would be super appreciated.

Thank you

You may want to enter your address into one of the many blockchain "services" webpages, for example: https://blockchain.info/

On the top right you can enter an address, and see if you have a balanceon your address...


Segwit transaction size not smaller In this transaction;
https://blockchain.info/tx/573700fe19dbc926d037ee67dbe882ebcf3f765f1a3fcc9577665ba40554485f

All of addresses are segwit. According to my research this transaction size must be 166 bytes. But is seems 248 bytes.

Is there any idea?

You are mistaking virtual size that got introduced with SEGWIT with the legacy size.

166 bytes is the virtual size. 248 bytes is the legacy one. Unfortunately, Blockchain.info shows only the legacy size.

You can check your transaction with smartbit to get the VSize.

You can also check this awesome article about SEGWIT fees calculation


How many peers it MultiBit connected to? Can not send bitcoins I have received bitcoins from an online wallet and I am now trying to send 0.05 BTC to another address. I have by now figured out that I need to set at least 0.0001 BTC as a sender fee (that error message was confusing, because it appears before has the opportunity to set that fee!).

I am now getting the error message “MultiBit must be online and connected to more than one peer to send bitcoin”. I can see from the status in the lower left corner that MultiBit is online, but I can not see the number of peers.

How can I check the number of peers?
Why is MultiBit not connected to more than one peer (if any)?
How long can it take to connect to more than one peer?

I am using MultiBit 0.5.14 with Ubuntu 13.10.

You can hover over the "Online" indicator to see the number of peers.

It should only take a few seconds to find more peers. This is dependent on the Bitcoin network though. You can force MultiBit to attempt to connect to a whole new set of peers by restarting it.


How do I send Bitcoin from my cold wallet to a new one? I have the public/private keys for my cold wallet. I want to move it all into an Electrum wallet. I understand that I should send my entire balance at once. What medium should I use to make this transfer? I do not want to use Mycelium or any phone based wallet.

Side question: If I want to be able to spend small amounts of Bitcoin on purchases what is the ideal wallet setup I should be using?

Funds from a cold wallet need to either be imported or swept (for cybersecurity reasons sweeping is always preferred over importing) into most any hot or warm wallet to then sent to another cold wallet address synthesized from private keys that are usually in either the Wallet Import Format (WIF) or in BIP 38 standard format (is AES encrypted and starts with the letters 6P). Wallet imports or sweeps usually take WIF or BIP 38 input formats that have associated input error checking versus raw hexadecimal that a prone to human input errors like Ethereum.

Electrum is not technically a cold wallet unless the Electrum BIP 39 seed words have never been loaded into an Electrum warm wallet.  An Electrum wallet is warm only if it uses a hardware wallet such as a Trezor, Ledger or Keepkey token generators that have been loaded with BIP 39 seed words. Otherwise, the Electrum wallet is a hot wallet.

Cold wallets need the private keys and associated public addresses generated on a trusted offline computer. Cold wallets can use self contained JavaScript programs, or a standalone binary executable such as Bitcoin-Explorer (bx) running on air gapped computers that can also leverage brainwallets provided the brainwallets input text have sufficient entropy.

To answer your side question, you should be using a HD hardware token generator with Electrum to have warm wallet functionality, or you need to use multiple cold wallets probably using a trusted JavaScript key generator program, not a single cold wallet.


Understanding Bitcoin fees I am thinking about buying some bitcoin. I understand the risks and I am going to use the little money I have left at the end of the month. I have plenty savings as well, so I am not using all of my savings to bet on bitcoin. I just want to invest a very small amount to understand the mechanics of it.

I am trying to understand Etoros' fees as described here: https://www.etoro.com/en/customer-service/fees/. Coinbases' costs seem to be much simpler to understand.

To help me understand Etoros fees. Say I had £250 to buy today and I sold for £250 this time next week. What would the Etoro and Coinbase costs be and when would they be payable?

Also what is a pip? I understand it to be 0.001p but I could be wrong.

It's a bit apples and oranges. At Coinbase you are actually purchasing cryptocurrency that you then own and can move elsewhere if you wish, whereas at eToro you are opening a CFD (contract-for-difference) position, which is similar to trading futures in that you don't actually own any bitcoin but are rather speculating on the price movements of bitcoin.

At Coinbase, you pay a percentage of your total purchase price. You also pay a percentage fee when you sell. (Sidenote: By using their associated trading exchange GDAX, you can avoid paying these fees, but you'll need to learn how to use their interface).

With eToro, you pay a fee each day your position is open. That is why the fees are listed as "OVERNIGHT FEE (PER 10 UNITS)".

The conversion fee listed on eToro (in pips) is for if you are depositing in a different fiat currency than USD and they have to convert it for you; it doesn't have to do with crypto specifically. A pip is the smallest trading unit of the currency in question. For most pairs it is .0001, however Yen-based pairs are only displayed to two decimal places so it is .01 in that case.


How can counterparty tokens be distributed? When a new counterparty token is created, are they all created at once? Or can there be a custom distribution schedule? Basically, I'm wondering if all counterparty tokens are centrally distributed or if there can be a way to distribute them in a decentralized way.

Another way of asking this:

In Bitcoin, mining serves two purposes:

To secure the blockchain and make it hard to overpower
To distribute coins in a decentralized way

Is there a way to use counterparty for (1) but still do mining for (2)?

1) Yes, as of now (v9.55.1) it's all at once. BUT, you can increase the issuance by issuing more later unless you "lock" the issuance.

2) So yes, there can be a custom distribution schedule. Example: start with 100, run a "stakeholder" vote via Counterparty broadcast or other method or decide by yourself as the issuer, then increase issuance to say 200. But, if you lock issuance, then it's impossible to issue additional quantity of tokens.

Another way of answering your rephrased questions:

1) Counterparty relies on the bitcoin blockchain (and the miners) and it doesn't have its own miners. The native currency (XCP) was created by proof-of-(bitcoin)-burn. Tokens/assets are created by burning a small amount of XCP

2) Coins (tokens/assets) can be distributed in any way you want, it's independent of pretty much anything - for example you could simply ask people to provide their verified address (which they could do in any number of ways that bitcoin supports, for example by signing a message) and send them some tokens. There's a faucet (google it) that works similar to bitcoin testnet faucets and you could use that as well.


Closed wallet on MultiBit, found it in AppData, but when I click "open" nothing happens I have clicked on "close wallet" by mistake, and thought it was lost, and then found it in C:\user\<my name>\AppData\Roaming... but, when I click to open the wallet nothing happens.

I have saved my private keys to a USB stick, and my public address is written down (this wallet is in MultiBit). I have Windows 8.

Is it possible to recover my wallet?

There is a bug in v0.5.15 where if you close a wallet and then reopen it straight away the screen does not refresh. If you shut down multibit and then start it up again you should see it.


How to track multiple bitcoin addresses? Let's say I have multiple (N) wallets, with N public addresses and N private addresses. Is there a simple way to track the balance (and transactions, but this is not so important) of those wallets? Ideally I would install an android app with the capability of adding public addresses that allows me to see the balance of those addresses.

I do not need to be able to spend from those wallets, just to be able to see the balance. That is, I do not need to import the private addresses, just the public ones.

usually you can use block explorers to display amounts of your different bitcoin addresses. I tend to go to "blockchain.info". As it is cumbersome to cut and paste everytime, I created a small (Linux/MacOS/OpenBSD) shell script to do this for me (https://github.com/pebwindkraft/ccy_values). There are payed APIs and non payed APIs, the latter one having a limit on requests.


Pruning Blockchain, what does it remove? I am trying to determine if I want to prune but I'm trying to figure out if it would interfere with anything.
Would it interfere with rpc calls to show info on a transaction/block? A full explorer?
Does it interfere with showing transaction histories?
I finally have the full blockchain downloaded and it takes a long time so i want to be sure. I don't need the extra space.

Pruning Blockchain, what does it remove?

What
Raw block data for blocks older than a given height.
If we look at https://bitcoincore.org/en/releases/0.11.0/, it says

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

So if raw block data and undo data are deleted that presumably leaves the block index and the UTXO set as the two of the "four types of data" that are unaffected by pruning.

...
Modified RPC calls:
getblockchaininfo now includes whether we are in pruned mode or not.
getblock will check if the block’s data has been pruned and if so, return an error.
getrawtransaction will no longer be able to locate a transaction that has a UTXO but where its block file has been pruned.

So some RPC calls return an error for pruned data.
When
However the most recent 288 blocks are kept (approx 2 days worth) regardless of whether all their transaction outputs have been spent.
There are some additional details about the timing of deletion of files that contain multiple blocks that are individually marked for deletion. I don't think this substantially affects this answer but it may be something that you should study - depending on what you are trying to achieve.

Would it interfere with rpc calls to show info on a transaction/block?

Obviously, if the block has been pruned it would hamper the ability of the node to report on it. As mentioned above, some RPC calls will return an error if a block has been pruned.

a full explorer?

Ditto.

Does it interfere with showing transaction histories?

It may interfere with showing the history of arbitrary transactions but you should still be able to view all transactions that were created by this wallet/node.
I think you wouldn't always be able to immediately retrieve full details of the sources of transaction inputs back through prior transactions all the way back to the "coinbase" transaction that created the money currently being controlled by the pruning node.
So it may depend what you mean by history?

transactions previously created by this node
historical transactions referred to by own "live" transactions directly or indirectly.

I think the intent of a pruning node is that it should be fully functional as a personal wallet but require much less disk storage space.
If you are using it as something other than a personal wallet you may find that there are significant disadvantages you have to explicitly work around. I guess it depends on the precise details of the intended usage.

See

How do I get old blocks while running a pruned node?


How can you restore a password in MultiBit if you are given the wallet words BEFORE you even enter a password? How is it possible to recover a wallet password when the wallet words are provided before you even enter the password?

https://multibit.org/en/help/hd0.1/restore-password.html

  Restore password

  If you forget your wallet password, then you can restore your password from your wallet words.

There is a copy of the password stored encrypted with an AES key derived from the wallet words.

Thus if you forget your password and still have a copy of your wallet you can use your wallet words to recover your password.


How exactly is Rucoin different than Bitcoin? Rucoin is a "Russian Bitcoin clone" (see announcement thread).

Besides the fact the website is in Russian, what other characteristics does this coin have?

Is it just a 1-to-1 Bitcoin clone? Is mining limited to clients from Russia? This post claims that

  Rucoin provides some tools functionally similar to central bank and
  the stabilization fund, whose main task - to make the course of
  crypto-currency stable, predictable and guaranteed.

Does anyone know how they claim this is achieved ... or in other words, how exactly is Rucoin different than Bitcoin?

The "author" (if you can call a blatant 1:1 copy of Bitcoin authoring) has not backed up those claims.

The website provides no further explanation and a lot of vague nonsensical "answers"

A crude but human translated English version of Russian homepage is here:
https://bitcointalk.org/index.php?topic=48582.msg586451#msg586451

  What is the specifics of the Rucoin?
  In short - more stable course

  It is difficult to talk about stability when the system is at the forefront of the struggle of interests.
  Constant fierce struggle of interests causes course instability, which creates a number of disadvantages for practical use of such currency.
  Another thing - Rucoin.
  This project was not born on the battlefields. At the heart of Rucoin - ready, proven solutions and lessons learned.

Those "solutions" and "lessons" are never explained except with vague double speak.

  Conceptually, Rucoin - this is a layer of stability and security, when, instead of blind hope for "the invisible hand of market" principles are used strict currency regulations. Instead, to give the exchange rate at the games speculators, who for the sake of their earnings will generate most unpredictable chatter in the system, Rucoin provides some tools functionally similar to central bank and the stabilization fund, whose main task - to make the course of crypto-currency stable, predictable and guaranteed .

  Rucoin, unlike Bitcoin, totally unsuitable for currency speculators, but it is very suitable for the conservation and savings to ensure a stable and reliable infrastructure of payment systems new generation.

  In addition, Rucoin towards Bitcoin may well serve as a reserve currency, into which can be converted part of the funds for the insurance of all kinds of surprises.

So the author claims to implement a central bank and stabilization fund but makes no mention on how that is possible or how it will be implemented.  Given that exchange and a direct to cash mining pool were launch prior to the actual block chain my suspicion is this is merely a poorly designed pump and dump.

Since the launch the author has not provided any further information on how the claims will be implemented.  Based on the volatility seen at http://btc-e.com (largest exchange offering RUC trades) there has been no "currency regulation", "central bank" action or effective use of this so far unseen "stabilization fund".


No confirmations, waited for months! I sent a payment of 0.9995 bitcoins back in April to my MtGox account. However I just checked and it has 0 confirmations. Additionally it doesn't show in my wallet or my MtGox account. Is it lost? Can I get it back?

If your transaction from April still has no confirmation, it would be feasible to create another transaction that spends the same input to yourself. You could hope that your new transaction would be verified first, which would invalidate the other transaction and salvage your coins.


how does the creator of Bitcoin get paid? Is the exchange the only people making money of the purchasing of bitcoin or is the creator profiting as well?

The creator, Satoshi Nakamoto (referred to as a "he" hereafter even though it might be a woman or a group of individuals), seems to have mined many of the early Bitcoin blocks. There have been several analyses identifying blocks mined by a specific single program, based on the nonce and so on, and it is mostly rational to assert that this was Satoshi.

There are other theories as to who this miner is, but it is naive to imagine that the system's creator wouldn't at least be somewhat interested in mining and supporting the network, and the evidence is consistent with that.

Either way, those mined coins have not moved as yet, and it is possible that he burned the private keys for them.

Of course, it is likely that there are other blocks he mined that have not been identified as his, and he has a reasonably sized stash he can spend as he sees fit.


How does the Segwit2x fork implement replay protection? The creators of the Segwit2x fork claim that they are working on some sort of replay protection. What replay protection do they have and how does this replay protection work?

segwit2x temporarily had an opt-in replay protection, but chose to remove it.

it is intentional, as part of their strategy to make only one fork survive.


What does the Sender of a Transaction include in the Input that allows the Recipient to Unlock/Redeem? I have been struggling to grasp what exactly is included in the input of a Transaction that allows the intended recipient to then redeem/unlock that UTXO when they are ready to do so.

I understand that a transaction contains a Digital Signature created by the Senders Private Key on the message.

I become confused when trying to understand what data the sender includes in the Transaction that allows the recipient to unlock that UTXO and turn it into a subsequent input when they choose to do so. Is the Sender including the Recipients Public Key in the Transaction allowing them to use a scriptSig to unlock that UTXO?

Thanks for taking the time out help

The transaction output has a property called the scriptPubkey that is executed with the scriptSig when the output is spent in a transaction. An understanding of Bitcoin script would help.

Bitcoin Script

Bitcoin uses it's own stack-based scripting language with a set of op-codes. This scripting language is used to determine whether an unspent transaction output (utxo) can be spent. When you send Bitcoin, you are really just assigning a Bitcoin value to a script, which can be spent only if the script executes successfully and results in a single true value on the stack. The script that is assigned to the Bitcoin transaction output is called the scriptPubKey. To satisfy the script, you must provide the correct scriptSig, which is also a script, which is prepended to the scriptSig and executed to test if the spending succeeded. Let's look at an example:

scriptPubKey (raw): 76a914306e2ea1eed91bf66dfe5d94f3957d4ba63bde8488ac
scriptPubKey (assembly): OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG

In plain english, this script, when executed will do the following:

OP_DUP: Duplicate the top item on the stack (place a copy of it on the stack)
OP_HASH160: Pop the top item off the stack, calculate it's HASH160, i.e. the  RIPEMD160(SHA256()), and place that on the stack
OP_EQUALVERIFY: Pop the top 2 items off the stack, and if they are not equal, it will exit immediately and fail, otherwise nothing
OP_CHECKSIG: Pop the top 2 items off the stack, and use the top as the public key, the second as the signature, and verify the transaction signature

In order to spend this output, we must provide a valid signature and public key. We'll just provide 00 for the signature for this example, and not worry about the final checksig op.

Example

Let's visualize this example with a scriptSig. Let's use kallewoof's btcdeb Script visualization tool. After the first command, you can type step once, and then just press enter each time after that to step through each operation:

$ btcdeb '[00 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG]'

btcdeb -- type `btcdeb -h` for start up options
valid script
7 op script loaded. type `help` for usage information
script                                                             |  stack
-------------------------------------------------------------------+--------
0                                                                  |
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0000 0
btcdeb> step
        <> PUSH stack
script                                                             |  stack
-------------------------------------------------------------------+--------
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |      0x
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0001 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_DUP                                                             | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_HASH160                                                         |                                                                 0x
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0002 OP_DUP
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_HASH160                                                         | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_EQUALVERIFY                                                     |                                                                 0x
OP_CHECKSIG                                                        |
#0003 OP_HASH160
btcdeb>
        <> POP  stack
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_EQUALVERIFY                                                     | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_CHECKSIG                                                        |                                                                 0x
#0004 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
btcdeb>
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_EQUALVERIFY                                                     |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_CHECKSIG                                                        |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
                                                                   | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0005 OP_EQUALVERIFY
btcdeb>
        <> POP  stack
        <> POP  stack
        <> PUSH stack 01
        <> POP  stack
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_CHECKSIG                                                        | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0006 OP_CHECKSIG

You can play around with this using any of the opcodes listed at Script.


Is it possible to extract legacy address from segwit address? After 24 aug 2017 starting from block #481824 blockchain DB consist transactions with the segwit-addresses.

For example (have a look to the address, specified in the output):
https://btc.com/461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6

address
bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
or (how I understand it is the same address, but in another format)
cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70

I have to notice that only btc.com parsed this output (for example, blocktrail.com or blockexplorer.com couldn't parse this).

In the same time json-rpc of bitcoin-core client couldn't parse this address too.

[vout] => Array
(
[0] => Array
(
[value] => 0.005
[n] => 0
[scriptPubKey] => Array
(
[asm] => 0 cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
[hex] => 0020cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
[type] => witness_v0_scripthash
)
)
)

How we see - no section "addresses" in the section "scriptPubKey" (in case of "legacy" addresses json-rpc returns information about the addresses).

So what I want to ask:

1) What is the difference between
bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
and
cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
? Is it different formats of 1 address?

2) How could I know hash of legace-address of the followed transaction? Is it possible? May be I have to parse scriptBubKey hash for this?

3) Why bitcoin-core json-rpc doesn't provide this info? I use last version of bitcoin-core client.

Thanks a lot for the any information.

While technically it is possible to generate one address from another, after all they are simply representations of public keys, it is strongly discouraged to do so, if you are not the owner of the address (at which point the wallet should provide you with an option to use either format). The problem is that if you send a transaction to a segwit address, that the recipient is not expecting/supporting then they will not recognize the payment.

Now for the apparent aliasing you mention above: the recipient address of the transaction you link to is a P2WSH (pay-to-witness-script-hash) address. cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70 is the hash of a script that currently only the owner knows (until an output to that address has been spent). The bc1... representation is the bech32 encoded BIP142 address, which includes a checksum and a human readable currency identifier bc. It contains exactly the same information, i.e., a P2WSH script of the form `0 .


How malleability ussue works? Can you explain malleability issue, please?

This is what I read here: https://qz.com/175565/why-nobody-can-withdraw-bitcoins-from-one-of-the-currencys-largest-exchanges/

"When a transaction record is sent out to the network of bitcoin miners, it’s possible for a hacker to tweak it enough to change the hash, but not enough to make the transfer invalid. One of the ways the hacker can do this is by slightly modifying the digital signature in a way that it is still recognized as the right signature, but, again, results in a completely different hash."

I can't understand how, say, Bob can change Alice's signature in a Alice->Bob transaction if that signature doesn't belong to him in the first place.

First of all, exchanges keep track of transactions by their TXIDs. The TXID can be changed by 3rd parties, but not the transaction data.

  I can't understand how, say, Bob can change Alice's signature in a Alice->Bob transaction if that signature doesn't belong to him in the first place.

Old versions of Bitcoin Core used OpenSSL to verify signatures (now libsecp256k1). OpenSSL is lenient about signature encoding.

An ECDSA signature is an (R,s) pair. (R,-s) also makes a valid signature.
OpenSSL allows encoding algorithms other than DER.

which means there are more than one possible way to encode signatures. Different but equivalent signatures allow 3rd parties to change the signatures without knowing the private key, thus changing the TXID.

Details: BIP 62


Would there be a problem introducing opening-balance transactions in bitcoin? For example, every 10,000 blocks, the new block would propose an opening balance for all addresses that are still being mentioned in the blockchain with non-zero unspent outputs. It would be an opening-balance transaction.

All validating nodes must then recompute the opening-balance transaction and verify that it is correct, after which all previous transactions in the blockchain can be deleted/forgotten. It would effectively be a new genesis block.

It should allow validating nodes to free a lot of disk space and permit nodes with less capacity to participate in the network.

Is there a reason that prevents us from introducing this?

Is there a reason that prevents us from introducing this?

How will you download and validate the full blockchain if nobody around you has the full blockchain but has only "pruned" version of it started from block #xx0000?


Are sellers more vulnerable to fraud than buyers when doing business? The Bitcoin white paper says:

  Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. ... Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.

My understanding is that Satoshi decided to protect the sellers and this seems to suggest that he thought that sellers are more vulnerable to business fraud. (He surely didn't mean that buyers are not important, but his design decision favors the sellers, I think.)

Is there any existing evidence, report, or statistical data that support that sellers are more vulnerable to fraud?

My interpretation is more that, since sellers are the ones receiving money, they are the ones who stand to be protected by an improved and non-reversible payment system.  I don't think Satoshi particularly thought that protecting buyers (who are receiving goods) was less important or that they were less vulnerable, but that it simply wasn't within the scope of the problem he was trying to solve.  He thought that "routine escrow mechanisms" were already appropriate to the task, and in a decentralized currency, these mechanisms can be decoupled from the payment transfer system.


Transaction not complete for two days now I sent bitcoins to a wallet using the QR code in order to be very sure of the address. It shows in my wallet that it has been sent. But the receiver haven't seen it in his wallet. I checked it online and it shows that the money is in the address.  How can i do for him to see his coins or if not get?
I sent it to this address.
Note: the transaction shows confirmed

1N9V3yNuBEbgS3g87qibrnTGARj9SrKFst

1N9V3yNuBEbgS3g87qibrnTGARj9SrKFst did receive bitcoins. If they ask you to send again, don't, it might be a scam.

You can give them the transaction ids:

170e84bcc871f4cca8d352035c4bbe9e1a44bf2f66c8e9e4ff69547ea1256639
d1b5b5fddfde0aa492f8ef8a58f6740222ceed42d2ee369082ea4e95f7233415

even though they don't need them. You can just tell them "on block explorers it the transactions are shown as confirmed." with a kind "Can you confirm that the output address 1N9V3yNuBEbgS3g87qibrnTGARj9SrKFst shown on the block explorer was the one you had given to me?"


how to create web wallet for bitcoin I want to create a web wallet for bitcoin in which anyone can create their account and do the transactions but my node allow me to create one desktop wallet only. so i am not getting how this webwallet will work for multiple users.

Bitcoin core does not support multiple users with separate addresses in a single wallet.

Neither does it provide for running a wallet service to other people.


How are public & private keys in an address created? I understand the high level concept I am more interested specific details.   How is a private key generated.  How exactly is public key generated, how is address generated from public key.

As is normal when doing Elliptic Curve encryption, a private key is simply a random number. In the case of secp256k1, the elliptic curve used by Bitcoin, it has to be a number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336 (or in hexadecimal, between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140).

This private key is converted to a public key by performing an EC point multiplication with the curve's base point. The result is an (x,y) coordinate pair, which constitutes the public key.

Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of those coordinates, is computed, and encoded in base58, together with a checksum. This becomes the address.


Can anyone explain me why I can not buy coins at the advertised price Right now I see on mtgox the lowest price as 105$ and the last price 165$ but when I want to buy by the price of 105$ I can not do so, the only option is 165$.

Is there something I understand wrongly?

That was the lowest price in the past day, not the market price.


I am unable to figure the getwork api I called bitcoind getwork slightly earlier in the day and this is what I got:

{
    "midstate" : "6d8b2d759123e7311c552f0c99f6d520378062ac7a14fb11f6d433779d282faf",
    "data" : "00000002c2bf65e9637a1c11955c2ba1c45c9bffad322d4fa0d9529e0000014300000000e9587c30863f5f410ea9d0611d3da6b7d0afd390b4b8e33cd71297c9d20dc74651ad7ea71a01616400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
    "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
    "target" : "0000000000000000000000000000000000000000000000646101000000000000"
}

So for the time being lets throw away the midstate which I will not be using since I am only trying to understand.
So now doing the 32 bit byteswap on the data I get this:

Data
02000000 e965bfc2111c7a63a12b5c95ff9b5cc4 4f2d32ad9e52d9a04301000000000000 307c58e9415f3f8661d0a90eb7a63d1d90d3afd03ce3b8b4c99712d746c70dd2 a77ead51 6461011a 00000000

Now I am unable to figure out how to actually read this information. According to the wiki, the first 4 bytes are version. Here the first 4 bytes are version.

Version:
02000000

Isnt it supposed to be 2. The above is a really large number in big endian.

Now the previuos hash block:

Hash:
e965bfc2111c7a63a12b5c95ff9b5cc44f2d32ad9e52d9a04301000000000000

I am unable to find this hash anywhere on blockexplorer or block chain info? I tried to change the endianess once again but to no avail.

Finally I left the merkle root out and tried to confirm with the utc time:

Time:
a77ead51

Which corresponds to the year 2081. What exactly am I doing wrong here?

Isnt it supposed to be 2. The above is a really large number in big endian.

It's a small number in big endian. Think about it; big digits at the end.

  Now the previuos hash block

I don't know why Bitcoin does this, but block hashes are stored in normal order internally, then byte-reversed before displaying them.

>>> s="e965bfc2111c7a63a12b5c95ff9b5cc44f2d32ad9e52d9a04301000000000000"
>>> import binascii
>>> s=binascii.unhexlify(s)
>>> s=s[::-1]
>>> s=binascii.hexlify(s)
>>> s

'0000000000000143a0d9529ead322d4fc45c9bff955c2ba1637a1c11c2bf65e9'

  Time:
  a77ead51

Use big endian. I got 1370324647 using this tool, then converted to 04 Jun 2013 with this tool.


rpcallowip=192.168.0.* ?? invalid configuration I recently downloaded bitcoin from github and changed the settings to allow for rpc.

This is how I have it:

rpcallowip=192.168.0.*

This does not work anymore.

However when running bitcoind, it complains that:

Error: Invalid -rpcallowip subnet specification: 192.168.0.*.
Valid are a single IP, a network/netmask or a network CIDR.

I'm not that familiar with networking.

Can someone tell me what a valid network/netmask or network/CIDR is for all addresses that could be in 192.168.0.*

You want to use 192.168.0.0/24. That's CIDR notation for 192.168.0.*.


How many letter tiles does one need to build any 24 word mnemonic? One of the popular cold storage wallets provides double-sided tiles for users to put in the first four letters of each of their 24 words (96 characters total).

They include ~245 double sided tiles, plus some blanks.

By my math on the BIP39 wordlist, they should need to provide ~485 double sided tiles to provide for every valid 24 word mnemonic.

I simply calculated, for each letter, the worst case 24 word combination, then added up how many of each letter I would need, then divided by 2 since the tiles are double sided.

Is there something I'm missing here?

Thanks!

EDIT  I have found at least one flaw in my reasoning. The last word is a checksum, so not entirely random. But accounting for this only saves us 33 letter tiles!

Actually the answer is rather simple, Cryptosteel did a letter frequency analysis on the bip39 wordlist and found that you can represent any word in the list using only 4 characters. Therefore, for a 24 word recovery phrase, you take 4x24 or 96 characters.

Edit: Oh oops, I thought the question was that ability to store all combinations instead of the tiles provided. to which my answer is, they probably ran an analysis and decided on that number of tiles based on their data. If it bothers you, you can just use a cold wallet that includes more tiles like simbit that includes 400.


What are some paid cryptocurrency exchange software? What are major exchanges are using ?
few of them have similar layout and trading system.

is there readymade crypto trading software available ? even paid.

Yes, ready-made crypto trading software is available. I have been shortlisted some of the crypto trading software provider across the world.

Coinsclone

BitExchange System

Trading Technologies

Draglet

BlockchainAppFactory


What program do I need to mining coins? I see there are hundreds of coins in the market. Can I use one program to mine all of them?

I assume you know that mining with personal computer isn't profitable.

On-topic:
There are a variety of algorithms, first you need to find out which algorithm the cryptocurrency you want to mine is based on.
Then find a CPU or GPU mining software that support that algorithm.

One CPU miner that is widely used, and support most of the available algorithms is CPUminer-multi .

You can find the latest about mining on this forum https://bitcointalk.org/index.php?board=160.0


Bitcoin in third world countries I am with the Adelante Foundation.  We are a microfinance institution serving the poorest of the poor women in Honduras. We are currently toying with the idea of transitioning into a cashless model using the Bitcoin and I had a few questions I was hoping you could help me out with.

I understand the benefits of going cashless and using the Bitcoin. I also understand the efficiency of approving loans and transferring money to clients. What I do not understand is how the clients use that money to pay for things. Since Adelante works in very rural areas, it's very possible they will need cash to make transactions, so how do they do that? Would all the vendors need to have some sort of software that supports Bitcoin?

Any light you could shed on this subject would be very appreciated!  Thank you so much!

Best,
Tim

Yes, if you're transacting with bitcoin, you will need vendors that accept bitcoin instead of cash. Furthermore, the clients and vendors will most likely need internet access in order to send bitcoins from one person to another.

It would probably help to know a little bit about how bitcoin works and how it's a global ledger system based on the blockchain. This answer should enlighten you a bit about the requirements.


How do I exchange the issuer of my BTC in Ripple? I see Ripple now has 2 Gateways, WeExchange and Bitstamp.
I sent 1 BTC to WeExchange, and got in return 1 "WeExchange BTC in Ripple".

How do I exchange it directly for 1 "Bitstsamp BTC in Ripple"?

The Trade page in the client doesn't seem to allow me to select BTC as both ends of a trade. I don't want to go through another intermediate currency, I think I'll lose a lot because of the margins - I expect that trading BTC issued by different exchanges should be relatively without spread.

It will happen automatically when you pay someone who only accepts Bitcoins from the other gateway. There are several different ways you could form transactions to do this, but I think the client doesn't currently give you an easy way to get to any of them.

In the Ripple system internals, people can create offers whose sides are the same currency but different issuers. However, you can also achieve the same effect without having to go through an offer (and likely at a lower cost) by using a circular payment path with no exchanges.

Again, you can't do this with the client currently, but here's how it works on the server side:

You have 1 WeExchange BTC. You want 1 Bitstamp BTC.
You form a payment path like this:
You/BTC -> WeEx/BTC -> ??? -> Bitstamp/BTC -> You/BTC
You hand this payment path to the server, telling it you want to get 1 Bitcoin out.
The server finds the cheapest way to do it. Most likely, it will find one or more people who have extended trust to WeEx/BTC and hold Bitstamp/BTC. You can use any of those people. (For safety, you can pick three to make sure your transaction goes through.)
With the three payment paths the server found you, you form a "Payment" transaction. Assuming all three of those people don't change their trust or balance settings before your transaction applies, the exchange is complete. Someone in the middle has your WeEx/BTC and you have their Bitstamp/BTC.

Note that if there's an exchange offer that gives you better than 1-to-1, the pathfinding scheme will use that instead. So you could wind up with more bitcoins out than in. (Though it's not likely.)

This actually will not allow you to get 1 Bitcoin out because you would have to pay two transfer fees to transfer the Bitstamp and WeEx IOUs. The total of the transfer fees is something like .7%, so you'd only get .993 Bitcoins out.

Instead, if you're not in a hurry, you could drop your credit limit to WeExchange to zero. This signals that you want to get rid of your WeExchange IOUs. Anyone picking a payment path like above in the other direction will try to accommodate you. Then they'd pay the transfer fees. (The current pathfinding algorithm doesn't always do this, but the new one scheduled to replace it shortly will be better at this.)


What is the most expensive part of mining? From my understanding, miner's take a bunch of transactions and use a nonce, previous block and the transaction data to try and find a hash that beats the difficulty. As soon as this happens, will their block be added, and then 99 blocks later the BTC will be awarded.

Is the solving aspect of the hash the most expensive part, for the computer? Or is gathering the transactions and confirming them more expensive?

How does one confirm the transactions? Do they have to traverse the entire blockchain, or only find the most recent ledger which shows both user's balances to confirm?

Is the solving aspect of the hash the most expensive part, for the
  computer? Or is gathering the transactions and confirming them more
  expensive?

Finding the nonce that produces the correct hash is by far the most computationally expensive part.

  How does one confirm the transactions? Do they have to traverse the
  entire blockchain, or only find the most recent ledger which shows
  both user's balances to confirm?

The blockchain is the only bitcoin ledger. One confirms transactions by confirming each of them. To confirm a transaction is valid it must satisfy certain rules. One of these rules is that each of transaction's inputs must be correctly signed.

Transaction's input comes from an output of some previous transactions. Bitcoin node that wants to validate the transaction maintains a list of all unspent previous transactions (this list updates regularly and contains only small part of the blockchain), so it can easily find the output that the current transaction's input points to. The output must be in this list of unspent transaction's. An output has all information to verify respective input's digital signature.

So the node that checks the block, makes the above input verification for each input of each transaction.


What BIPs are supported by the standard client Bitcoin Core? There is different BIP, each has a status. I read somewhere that BIPs are not considered part of the Bitcoin protocol until "active". Nevertheless, Bitcoin Core seems to support a number of BIPs that are in status "accepted".

Is there an official list on what BIPs are currently supported by the standard client?

I even searched the source code but didn't find any official list.

The concept of 'accepted' is pretty fuzzy, as it depends on what a BIP affects. Some things are wallet-only, or only affect the protocol, or are optional to implement for different implementations. When BIPs affect the consensus rules of the protocol (the rules which determine which blocks are valid), the whole network needs to adopt them in lockstep, though (true for BIP 16, BIP 30, BIP 34, BIP 62, BIP 65).

Ultimately, BIPs are just proposals, and different pieces of software are free to implement them or not.

Here is a list of BIPs implemented in Bitcoin Core v0.13.0 (see this link for an up-to-date list):

BIP 9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1  (PR #7575)
BIP 11: Multisig outputs are standard since v0.6.0 (PR #669).
BIP 13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669).
BIP 14: The subversion string is being used as User Agent since v0.6.0 (PR #669).
BIP 16: The pay-to-script-hash evaluation rules have been implemented since v0.6.0, and took effect on April 1st 2012 (PR #748).
BIP 21: The URI format for Bitcoin payments has been implemented since v0.6.0 (PR #176).
BIP 22: The 'getblocktemplate' (GBT) RPC protocol for mining has been implemented since v0.7.0 (PR #936).
BIP 23: Some extensions to GBT have been implemented since v0.10.0rc1, including longpolling and block proposals (PR #1816).
BIP 30: The evaluation rules to forbid creating new transactions with the same txid as previous not-fully-spent transactions were implemented since v0.6.0, and the rule took effect on March 15th 2012 (PR #915).
BIP 31: The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since v0.6.1 (PR #1081).
BIP 32: Hierarchical Deterministic Wallets has been implemented since v0.13.0 (PR #8035).
BIP 34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v0.7.0. The rule took effect for version 2 blocks as of block 224413 (March 5th 2013), and version 1 blocks are no longer allowed since block 227931 (March 25th 2013) (PR #1526).
BIP 35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641).
BIP 37: The bloom filtering for transaction relaying, partial merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since v0.8.0 (PR #1795).
BIP 42: The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in v0.9.2 (PR #3842).
BIP 61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185).
BIP 65: The CHECKLOCKTIMEVERIFY softfork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only CLTV was added in PR #6124.
BIP 66: The strict DER rules and associated version 3 blocks have been implemented since v0.10.0 (PR #5713).
BIP 68: Sequence locks have been implemented as of v0.12.1  (PR #7184), and have been activated since block 419328.
BIP 70 71 72: Payment Protocol support has been available in Bitcoin Core GUI since v0.9.0 (PR #5216).
BIP 111: NODE_BLOOM service bit added, and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
BIP 112: The CHECKSEQUENCEVERIFY opcode has been implemented since v0.12.1 (PR #7524) and has been activated since block 419328.
BIP 113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566) and have been activated since block 419328.
BIP 125: Opt-in full replace-by-fee signaling honoured in mempool and mining as of v0.12.0 (PR 6871).
BIP 130: direct headers announcement is negotiated with peer versions >=70012 as of v0.12.0 (PR 6494).
BIP 133: feefilter messages are respected and sent for peer versions >=70013 as of v0.13.0 (PR 7542).
BIP 152: Compact block transfer and related optimizations are used as of v0.13.0 (PR 8068).


Is Quickbitcoins.net gone with all money? Site is down, google finds no new address. Can find nothingness on bitcoin forums, but Gregor not brightest crayon, perhaps doesn't know how to search.

The site was shut down in November and the former operator claims to no longer be involved with the service.

That operator is now attempting to raise funds for a new venture, Ziggap.

QuickBitcoins didn't take deposits.  They were a service used to buy coins for immediate delivery or for selling coins with immediate cash-out.

If you are owed bitcoins or funds from a cash-out transaction, the operator at the time would still be responsible for that liability, regardless of whatever disclaimer is provided about now "no longer having any relationship" with the service.


Theory: brute-force key search Let’s say I want to generate many private keys so I can generate one private key (and thus a public key) identical to the richest bitcoin address.

But I can’t do that because my computer power is not enough.

What about if I create many machines, like the mining machines, but instead of generating hashes, they would only generate private keys, Let’s call them “Keying machines”

So I have many of those Keying machines generating thousands of thousands of thousands of private keys per minute.

These machines will only stop if and only if they recreate the private key-public key of the richest bitcoin address : 385cR5DM96n1HvBDMzLHPYcw89fZAXULJP )

Is this idea actually possible?

Sure, it's possible. In fact, this is exactly what the Large Bitcoin Collider does - It has successfully located a few private keys, mostly from a puzzle transaction that seems to have been made to test its progress.

That said, it would still take you an unreasonably long amount of time - The Large Bitcoin Collider took 1 year and 3 months to search 8,000,000,000,000,000 keys (8000 trillion).

There are 2^256 possible keys. Even if you are able to search 1000 trillion keys per second, it would take you 2.7×10^44 × age of the universe to go through all the keys. It's simply not feasible.

As pointed out by G.Maxwell in the comments, the Large Bitcoin Collider should be not be interpreted as a viable, secure, or even reasonable approach to this problem. There have been concerns about its safety and accuract (reddit source).


Detecting unconfirmed double spends using bitcoind I want to get statistics on how many percentage of unconfirmed tx in the mempool are having attempted double spends and having what value. For this I want to get notification when an unconfirmed tx arrives that is conflicting with existing tx in mempool. I understand that bitcoind will accept the first transaction it sees and reject the next one, can I configure/patch bitcoind to send me notification on such double spend attempt ?

PS: I understand that a double spend can happen by directly including new tx in the next block without ever showing up in unconfirmed tx list. I think that requires direct access to mining pool and enough guarantees that the block will be mined. For my experiment, I am fine with ignoring this case as it has low probability.

bitcoind has a debugging option named mempoolrej. You can enable this by adding

debug=mempoolrej

to your bitcoin.conf file.

This debugging options tells bitcoind to print out information about the transactions that it rejects from the mempool, including why. You can thus enable this option and tail and grep the debug.log file looking for the string

was not accepted

This string is only found in the mempoolrej message which is of the form

<txid> from peer=<peer id> was not accepted: <reason>

The reason you are looking for is txn-mempool-conflict. So you can tail and grep for the entire string:

was not accepted: txn-mempool-conflict

Then with some bash-fu you can make this notify you whenever this string is found in the debug.log file.


Sent BTC to BCH wallet I have seen this question pop over a few times but I did not find an answer I could understand. This is the scenario:

I created a BCH wallet, mistakenly thinking it was a BTC one.
I bought BTC and sent to the BCH address
Realizing the mistake, I created a BTC wallet using the BCH passphrase.

Is what I did correct? Am I likely to see my bitcoins? Should I do anything else? How can I check where the purchased coins are?

Your method is correct: you'll need to use the mnemonic seed phrase that generates the bch wallet, to generate a btc wallet. If you do that, you should see your btc balance.

To see if your btc are at the address you sent them to, just use a block explorer website such as blockchain.info. When you use the mnemonic to generate a btc wallet, it should show you the sae addresses as the bch wallet (as long as the software uses the same derivation scheme. Most software does).


What are the arguments for and against using the Lightning Network with Bitcoin? In addition to the question in the title, when will Lightning Network go online, or, if there isn't a proposed date yet, what is a ballpark indication of when it might go online?

pros:

Lower Transactions Fees
More Transactions per second / block possible
micropayments possible
payments are more private than on bitcoin

cons:

funds are on a hot wallet
(at least currently) node needs to be online all the time
still somewhat buggy
(at least currently) only small amounts can be routed


Based on a certain amount of addresses, is it possible to find out how many bitcoins a specific wallet includes/owns? Based on a certain amount of addresses, is it possible to find out how many bitcoins a specific wallet includes/owns?

E.g. I have a blockchain.info wallet. If I create 1000 bitcoin addresses, fill them with 1 bitcoin each. The blockchain.info wallet, will show me the total  balance of 1000 bitcoins on my wallet.
If I share one of this addresses with someone, will he be able to find out that I have a wallet with an overall amount of 1000 bitcoins?

Short answer: No.
Long answer: It depends.

The addresses themselves are independent (unless blockchain.info has bugs that prove otherwise*) and no one can tell just by looking at them that they are contained in the same wallet.

However, the way you sent 1 BTC to each of those addresses and/or the way you will be spending that money later on, might betray you! For example if you buy one Ferrari for 1000BTC, combining all those bitcoins in the wallet in one transaction, then others looking at that might conclude that you were the owner of all those addresses afterall. Similar if you have 1000BTC in 1 address and then split that up and send 1 each, onlookers might suspect they're still yours.

*) Note that blockchain.info has a horrible track record of generating bad private keys, causing many bitcoins to be simply stolen.


Replace-by-Fee vs Child-pays-for-Parent? Both RBF and CPFP attempt to solve the problem of transactions not confirming because of an insufficient fee. What are the pros/cons of using one vs the other?

Are both currently functional and available for use on the bitcoin network?

Replace-by-fee means transactions spending the same coin to the same addresses are not considered double-spends by the network and are still relayed, as long as they pay a higher fee than the preceding transaction.

Example:
Alice pays Bob with a coin worth 1 BTC, sending 0.5 BTC to Bob, 0.49995 BTC to herself as change, and 0.00005 BTC to fees. Alice sees that her transaction is quite slow to confirm, so she sends an identical transaction (spending the same coin), but with twice the fee. The network relays the updated transaction and rational miners quickly mine the higher fee transaction.

Child pays for parent means, as the name implies, that spending an unconfirmed transaction will cause miners to consider confirming the parent transaction in order to get the fees from the child transaction included in the same block.

Example: Eve spends 1 BTC at a shop owned by Alice. But Eve is greedy: she only pays the bare minimum fee, and her transaction will take hours to confirm. Alice spends Eve's transaction to her banker Bob, but this time with a higher fee. Miners will now want to confirm Eve's cheap transaction in order to be able to include Alice's more rewarding transaction in their block.

RBF is currently live since 0.12, but is opt-in for the spender: Unless the spender marks the transaction as replaceable with a non-maximal sequence number, the transaction is final.

CPFP is not a change in the protocol, but in miner strategy.
Since it is rational for miners to implement it (they make more money), it is expected that most miners do implement it. At least Eligius seems to have implemented it. As mentioned by Pieter in the comments, any miner using version 0.13 or above will mine using CPFP rules.

Which one should you use?

If you're the spender and want your transaction to confirm faster, use RBF. If you received a payment and are unable to convince the sender to up the fee, or the transaction is marked as non-replaceable, use CPFP.

Better yet, send your transaction with the proper fee the first time.


What are some of the Bitcoin inaccuracies in the CBS Show "The Good Wife"? The CBS Show "The Good Wife" had a series of shows speaking about the Bitcoin and its creation. Although the show is entertaining, it is prudent for those of you who know the truth to record it for historical purposes, not letting the TV drama perpetuate inaccuracies.

In case you haven't seen it, you can look here: http://www.cbs.com/shows/the_good_wife/video/2186658794/the-good-wife-bitcoin-for-dummies

For example:  Is there a Bitcoin manifesto written by Mr. Nakamoto?  Is it possible to embed a character string in the block chain?  Was Bitcoin incorporated?  Was there a lawyer involved who paid people to write code?  Has anyone accused Mr. Nakamoto of being a lawyer? (sorry Sir, I know this is a low blow).  Is Decode-a-thon the name of the conference where all the cryptologists go?

Is there a Bitcoin manifesto written by Mr. Nakamoto?

Not really. Satoshi wrote some political stuff, but not much. Mostly he focused on the technical issues. This article is the most political thing Satoshi wrote, and it sounds kind of like a manifesto:
http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source

The line from the show was very unlike anything ever written by Satoshi, though.

  Is it possible to embed a character string in the block chain?

Yes. Anyone can do it. Run strings -n 20 on blk0001.dat and you'll see all of the strings that people have put into the chain.

Notably, the very first Bitcoin block (created by Satoshi) contains this text:

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Also, after The Good Wife someone actually put "Stack is innocent" into the chain. :-)

  Was Bitcoin incorporated?

No. Still isn't.

  Was there a lawyer involved who paid people to write code?

As far as is publicly known, no one was ever paid for Bitcoin coding until after Satoshi left.


bitcoin exchange for other virtual (centralized) currencies i was wondering if there are any exchanges which trade centralized virtual currencies for decentralized virtual currencies. for example, air miles for bitcoin or vice versa. my thinking is that this might externalize the charge-back problem inherent with fiat currency - ie the problem where someone sends fiat to the exchange, in return for bitcoin, then claims the money was stolen or the transaction was somehow illegitimate, and the bank takes the money back off the exchange leaving the user having paid nothing for their bitcoins.

of course i'm thinking that the centralized virtual currency also would not have chargebacks, but this may not be the case? here are some examples:

linden dollars from second life
amazon coins
air miles
gift voucher codes

https://www.virwox.com/ is an exchange for virtual currencies, trading among other things Linden dollars.


How to setup Antminer D3 to solo mine to CANN wallet I am trying to solo-mine CANN using my Antminer D3 directly to the full node wallet. I would really like to start adding decentralization to small coins just for the heck of it, but I am having some problems.

CANN wallet config:

  server=1 listen=1 rpcuser=u rpcpassword=x rpcport=39347
  rpcallowip=10.0.0.* rpcallowip=* rpcallowip=10.0.0.214
  rpcallowip=127.0.0.1

I have bfgminer set up as a getwork to stratum proxy via the following command:

  bfgminer -o 10.0.0.162:39347 -u u -p x --stratum-port=3333

However bfgminer is outputting this error:

  SSM: No usable 2D work upstream!

and my miner shows the pool as dead!

I know the miner is connecting to the bfgminer proxy because it displays this a few seconds after i set the ip in the miner interface:

  0            |   0.0/  0.0/  0.0 h/s | A:0 R:0+0(none) HW:0/none

Full bfgminer output:

  bfgminer version 5.4.2 - Started: [2017-12-16 11:37:48] - [  0 days
  00:04:52]  Pool 0: 10.0.0.162          Diff:256k  -GWork
   LU:[11:41:48]  User:u  Block: ...9a1b9582e90dac52  Diff:256k (
  1.83Th)  Started: [11:41:48]  I:?  ST:2  F:0  NB:3  AS:0  BW:[ 20/  7 B/s]  E:0.00  BS:0  0            |   0.0/  0.0/  0.0 h/s | A:0
  R:0+0(none) HW:0/none

  --------------------------------------------------------------------------------------------------------------------------------------- NO DEVICES FOUND: Press 'M' and '+' to add

cross posted: https://bitcointalk.org/index.php?topic=2598430.0

Try:(Change IP 192.168.1.147 to your and try same PC wallet and miner)

cannabiscoin.conf

server=1
listen=1
rpcuser=cannabisuser
rpcpassword=cannabispass
rpcport=39347
rpcallowip=192.168.1.147
addnode=seed.cannabiscoin.net
addnode=seed2.cannabiscoin.net
addnode=seed3.cannabiscoin.net
addnode=seed4.cannabiscoin.net
addnode=seed5.cannabiscoin.net
addnode=seed6.cannabiscoin.net
addnode=106.70.242.145
addnode=108.61.10.90
addnode=115.28.42.60
addnode=136.243.217.171
addnode=137.74.104.135
addnode=144.76.237.39
addnode=148.251.8.18
addnode=162.255.117.105
addnode=171.232.8.87
addnode=178.12.190.117
addnode=178.15.70.226
addnode=188.60.110.76
addnode=192.99.200.144
addnode=194.135.90.175
addnode=198.27.68.86
addnode=205.251.171.136
addnode=207.171.249.66
addnode=209.188.18.52
addnode=213.32.6.132
addnode=213.55.176.213
addnode=27.3.20.109
addnode=40.141.98.2
addnode=45.48.182.104
addnode=65.31.179.140
addnode=78.251.112.84
addnode=85.214.23.49
addnode=88.10.240.5
addnode=89.204.137.211
addnode=93.87.143.138

sgminer  https://github.com/sgminer-dev/sgminer

sgminer -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass -I 13 -g 2 -w 256 --lookup-gap 2 --shaders 2048

cpuminer  https://github.com/tpruvot/cpuminer-multi/releases

cpuminer-gw64-core2 -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass
pause


Is there a tool that searches for a specific BTC amount in a specific date range? Suppose I want to search for a transaction of exactly 445 BTC in the date range 27 July 2013 and Aug 3rd 2013 ... is there an (online?) tool that has this kind of search capabilities?

Blockchair allow you to query the bitcoin blockchain with lots of parameter such as date, BTC output amount, fee amount etc...

Here is your request:
https://blockchair.com/bitcoin/transactions?q=time(2013-07-27..2013-08-03),output_total(44500000000)#

Unfortunately it bring no result but you can change the parameters


What if a country 100% denominated in a cryptocurrency loses internet connectivity to the rest of the world? Please assume a small island nation becomes 100% denominated in a cryptocurrency.

Now please assume that for some reason the rest of the world manages to cut if off from the rest of the internet for some extended period of time, eg 1 year or more.

During the time that is isolated, it of course is able to continue using the cryptocurrency; however, what happens when connectivity to the outside world is restored?

Will all of this nation's transactions be lost forever and reset to the time before connectivity was lost?

If the transactions can be somehow recovered, what happens to all mining fees on the island during disconnection?

If anything is lost, how could a protocol be altered to manage this eventuality?

I am just guessing here given the little I know about bitcoin and distributed databases.
This comes down to the how CAP theorem applies to the bitcoin blockchain DB.
CAP theorem states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

Consistency (all nodes see the same data at the same time)
Availability (a guarantee that every request receives a response about whether it was successful or failed)
Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

As far as I can tell it is not consistent. And will handle partitions for a short period.
(and you could argue that long periods of partition will break availability of some transactions)
Details of what I think might happen:
(If every one plays nice and someone makes a few tweaks to the software it will come back online)
The bitcoin protocol has (in simple terms) two sets of data that it transmits/stores.
One is the block chain which is the authoritative order that transactions occur in.
The other is a gossip of the transactions.
First of all transactions would gossip around the islands network, but they would not get confirmed. Even if there were miner nodes on the network. This is because the difficulty would be very high.
The chance of the miners on the island of finding a block would be very low. So the confirmations of the transactions would probably not occur.
The difficultly is only adjusted every 2016 blocks. But as the miners on the island can not find a block the difficulty will not change. The confirmations would become stalled.
Basically if every one trusted 0 confirms and didn't double spend (hint: that is not going to happen) you could carry on as normal (assuming your software will let you spend 0 confirmed transactions)
This could lead to the network collapsing.
However if someone changed their mining software to mine at a much lower difficulty I think the network could start confirming again.
Normally this would not work as then bitcoin network would very quickly drop your block in favour of a longer more difficult one. But since you are in a partition you would win (for now)
Lets assume the miner who modded his software didn't try to make any double spends (which he would only be able to with the money he has before the partition, and there are enough miners so there are not any 51% atacks.
2016 blocks after that the network would readjust the difficulty (to the sum hashing power of the pool) and every thing would hopefully stabilise.
Ok all seems fine the partitioned island network would carry on.
That is until then partition is reconnected. (Dun dun dunnnnnnnn)
At that point two things would happen.

A longer more difficult block chain would replace the island block chain as the authoritative chain. This would wipe out all of the island confirmed transactions.
The island nodes would start gossiping the transactions that had occurred on to the other (newly connected) main partition.
This is assuming that, between all of the islands nodes, some of the software had a full copy of the gossiped transactions.

I think it would take the same number of blocks as the longest train of island transaction for all of the island transactions to be confirmed on the network.
Every thing back to normal???
Yes (insert Lost reference) as long as no one got off the island; with their bitcoin wallet.
If some one made a transaction from their wallet on both the island and on the main network,
then their transactions on the island would be seen as invalid (like a failed double spend).
But that would also mean that anyone the island who had made a transaction based on that failed transaction would find that their transactions would also be invalid etc etc. In other words that one double spend transaction would be poisoned.
Also any coins mined during the partition would also be poisoned.
Everyone's wallets along the poisoned branch(s) would revert to the balance they had just before that poisoned transaction.
You could check for those poisoned transactions with some offline copies of the block chain; before you reconnected the partitions.
This would make for an interesting set of norms, for your islands culture:
Your island's economy would depend on the (threat of the) death penalty being applied to anyone who tries to make offshore double spends (or spend coins mined on the island).
(Miners could still make money through transaction fees)
The import of mining rigs would fetch huge quantity of bananas and coconuts (as that would be the only thing you would have left to barter with internationally (Since you no longer have a national currency and can't trade internationally with bit-coins) :P


Crypto wallet for payments with no deposit We are wondering how we can build a wallet that talks to our website and gives the user the ability to request a withdrawal of his funds. We do not know what is the right question for this type of functionality that we want to build is, so any advice would be much appreciated:

The flow would be the following ->
a: User got rewarded in crypto (BTC, XRP, ETH, LINK) (a digit on the database).
b: User withdraws his reward to their address.

The reward gets credited to the user's account (simply a digit on the database), and NOT to user's wallet address, as the wallet should NOT generate new addresses for deposits, as we do not want to allow deposits at all.

To help with the explanation, Bitcoin faucet websites have such functionality usually, where you can withdraw your earnings but not deposit funds in them.

Cheers

There are many layers to this question. Also, I'm going to assume using just Bitcoin, for simplicity. For other cryptocurrencies the procedure would be mostly similar with important differences mostly in the backend.

On the Bitcoin layer, the simplest solution would be to have a separate wallet for the website.

On the interface layer, you can have a simple form on your website where the user can input the address when requesting fund withdrawal.

On the backend layer, your website can use any wallet software with an API or CLI, Electrum should be good, but is just an example. This API or CLI could be then invoked to make payments to users.

Your server would necessarily have access to the private keys for the website wallet, therefore security should be an important consideration. The wallet file on the server needs to be protected and the backend of your website must properly check the withdrawal amounts, properly authenticate users and properly mitigate common attacks. If you don't have experience with website security, there are many potential holes that can open avenues for attack. Elaborating on them is beyond the scope of Bitcoin StackExchange. The important precaution would be not to keep more funds than necessary on the website wallet and deposit more as needed, manually, from a wallet on your own computer.

(This answer was edited by author as a result of a discussion in the comments)


Use multiple GPU's with oclvanitygen Does anyone know how to use multiple GPU's with oclvanitygen? I have these two:

Available OpenCL platforms:
0: [Intel(R) Corporation] Intel(R) OpenCL
  0: [Intel(R) Corporation]       Intel(R)
  1: [Intel(R) Corporation] Intel(R) HD Gra
1: [NVIDIA Corporation] NVIDIA CUDA
  0: [NVIDIA Corporation] GeForce GT 630M

What would be the command for using both of them if I want an address that starts with 1MYbtc?

-D 0:0 -D 0:1 -D 0:2  (etc for as many GPUs as you have)

Edit:  Sorry I'll clarify for future users..

 ./oclvanitygen -i 1address

gets me..

 Available OpenCL platforms:
 0: [Advanced Micro Devices, Inc.] AMD Accelerated Parallel Processing
 0: [Advanced Micro Devices, Inc.] Tahiti
 1: [Advanced Micro Devices, Inc.] Tahiti
 2: [AuthenticAMD] AMD FX(tm)-4130 Quad-Core Processor

So if I want to use the 2x GPU but not the CPU then I'll run..

 ./oclvanitygen -i 1address -D 0:0 -D 0:1

or if I want to only use the CPU then I'll do..

 ./oclvanitygen -i 1address -D 0:2

(yes you can use multiple processes so I could mine one address with one GPU and another with the other GPU)


getrawtransaction error? [Code -5] I'm trying to read raw transactions but there is a problem; Seems like getrawtransaction only works for recent transactions, old transactions give me the next error:

No information available about transaction (code -5)

Why is that? How can i see raw transactions from old transactions? When i say "old" its like from 5 days ago. I really need those transactions to get the sender addresses for each one, if "aging" is the case i can keep that data in my own database before it gets old but...Maybe it's not about old/new transactions, maybe there is another factor that won't let me read some raw transactions, you guys know something about that?

Here's how I'm using the command:

Working:

getrawtransaction 94628caff8b926f1247779aa687fc5cce5063f3389f291192ce1e52fae9a2655 1

Not working:

getrawtransaction 6e0f6cc64a08241c62eb93427923e95319c1e16db56ddeefa0c837944ce63d4b 1

Thank you!

Since bitcoind/Bitcoin-qt 0.8, no transaction index is kept anymore by default, as it is not necessary for validation in the new database model.

Instead, there is only a database of unspent transaction outputs, which has enough information to (slowly) locate transactions in block files. getrawtransaction uses this, but it only works for transactions that are not yet spent in the block chain.

If you want to be able to look up historical transactions, you need to set the txindex=1 configuration option (or start with the -txindex command line flag). As this setting can only be set when the database is created, you'll need to rebuild it from scratch (using -reindex).


What is mining intensity? Both Bitcoin and Litecoin have an intensity setting when mining.  What does this mean?

Yes, this is related to GPU mining. From cgminer's README:

  INTENSITY INFORMATION:

  Intensity correlates with the size of work being submitted at any one
  time to a GPU. The higher the number the larger the size of work.
  Generally speaking finding an optimal value rather than the highest
  value is the correct approach as hash rate rises up to a point with
  higher intensities but above that, the device may be very slow to
  return responses, or produce errors.

I would just leave it set to 'dynamic,' or --intensity d . That will adjust it automatically depending on how long it takes to complete work.
(nitty-gritty details)


Do transactions with old UTXOs take longer to confirm? Suppose I do a transaction with an UXTO created years ago. Would that take longer to confirm because miners would have to look further back in the transaction chain to verify it?

No.

The miners use Bitcoin Core or similar full node software to determine which transactions are valid and suitable for inclusion in a block.  Bitcoin Core maintains a database of all unspent UXTOs.  This database is constructed when the node first downloads the blockchain and is updated as new blocks and transactions arrive.  It's random access and any transaction, regardless of age, can be found by its ID in a very short time.


Should the BIP 39 mnemonic sentence checksum be eliminated from the standard? Does it do more harm than good? Should the BIP 39 checksum be eliminated from the standard? Should the BIP39 checksum be made optional to improve security?

No, I don't think the checksum should be removed or made optional. It doesn't do more harm that good.
Bip39 is a simple way to copy computer-generated randomness from the computer onto, eg a piece of paper. This Bip39 mnemonic sentence can then be used to restore your wallet, should you lose your computer. The checksum provides some degree of certainty on the correctness of the mnemonic you enter.
However, lately, people have begun to explore how to create their own randomness when creating a new wallet. This can be done with dice, coin-flips, etc. You might want to do this for example if you don't trust that the computer's random-number generator is doing its job well.
Since most wallets offer a way to restore a wallet using bip39 mnemonic sentences, people are trying to use that feature as a way to create new wallets from manually generated randomness. This is where the problem lies.
Actually, it's stated in the Motivation section of bip39:

This guide is meant to be a way to transport computer-generated randomness with a human-readable transcription. It's not a way to process user-created sentences (also known as brainwallets) into a wallet seed.

So we're actually using bip39 in a non-intended way, and that's why it's so awkward. The solution to this is not to modify bip39, but to acknowledge that we're doing it wrong.
Instead of entering manual randomness into a computer through bip39, we should invent other means of transferring the manual randomness into the computer. Some wallets already offer this. For example, ColdCard lets you input dice rolls one by one until you think you have enough randomness and then the device will provide you with a bip39 mnemonic sentence for you to backup on paper. That's one way to do it.
As you may have noticed, since writing about this on Twitter (cited in Michael Folksons's answer), Mastodon, and Reddit, I've changed my mind about this. I no longer think that making bip39 checksum optional is the solution. The solution is to not use bip39 to input randomness into a computer. The purpose of BIP39 is to transfer computer-generated randomness to a human, not the other way around.


How to make bitcoins from other cryptocurrencies? I want to know how can I convert other cryptocurrencies like BlackCoin or LiteCoin to Bitcoin. There are many cryptocurrencies out there and the main difference between most of them and Bitcoin is popularity. At the moment, Bitcoin is way more commonly accepted as a payment option than the other cryptocurrencies, so they aren't really useful or flexible at all... So please tell me and explain how can I do this!

The only way to convert them is by trading one for the other, or by going through a third currency.

Meaning:

Find a person or exchange platform that trades exactly the currency pair you want e.g. LTC/BTC or BLK/BTC.
Trade LTC -> USD -> BTC

Some exchanges trade a number of different altcoins, so they would lend themselves to do what you want. I have no experience trading anything but Bitcoin, but I've seen that for example HitBTC trades LTC/BTC, and BTER trades BLK/BTC.

I have used neither exchange and therefore cannot recommend them, just giving them as examples.


What is Gas Limit in Ethereum? What is the function of Gas Limit parameter in Ethereum?
Is it involved in mining or something else?

In Ethereum, gas is a measure of computational effort. To each operation, a fixed amount of gas is assigned (e.g. adding two numbers costs 3 gas, calculating a hash costs 30 gas, sending a transaction costs 21000 gas [1]).

Since computation is expensive (mind that it has to be done by every full node in the network), excessive consumption of gas needs to be discouraged. Therefore, each unit of gas must be paid for (in Ether) by the sender of the transaction that triggered the computation.

Unfortunately, it is often not easy and in general even impossible to know in advance how much gas a transaction will need eventually. Therefore, transactions have a gas limit field to specify the maximum amount of gas the sender is willing to buy. If the gas used exceeds this limit during execution, processing is stopped. The sender still has to pay for the performed computation, but they are protected from running completely out of funds.

The transaction gas limit also protects full nodes from attackers, who could, without a gas limit, make them execute effective infinity loops. If such a transaction would take longer than one block to process, it could never be included in a block, and, thus, the attacker wouldn't need to pay for it. [2]

Additionally, blocks, too, have a field called gas limit. It defines the maximum amount of gas all transactions in the whole block combined are allowed to consume. Similar to the maximum block size in Bitcoin (measured in bytes), its purpose is to keep block propagation and processing time low, thereby allowing for a sufficiently decentralized network. In contrast to Bitcoin, it is however not a constant. Instead, miners have the option to increase or decrease it every block by a certain factor. [3]

[1] See the Yellow Paper for a breakdown of operations and the respective gas costs (Appendices G and H)
[2] https://github.com/ethereum/wiki/wiki/Design-Rationale#gas-and-fees
[3] See the Yellow Paper Equations 40 to 42 for the exact rules


Do the keys that are derived from a BIP-32 HD wallet depend on an initial seed? I did not understand the concept of a seed in BIP0032 that well. Would you mind telling me do the keys that are derived from a key tree of Hierarchical Deterministic Wallet (HDW) depend on a root seed? In another words, do the derived keys differ for different root seed values or not?

Thanks in advance
Best Regards

The short answer is yes.

A real example is provided below that applies bitcoin-explorer (bx) client on a UNIX command line interface to synthesize a very simple "low entropy" Bitcoin brain wallet seed that is 256 bits in length:

% echo “Hello its me” | bx base16-encode | bx sha256
cc64b0cb02990d2a17ba0f4274df3e38448454da4fb22a9ca8d23944be144e1d

The $seed above feeds the synthesis process of BIP 32 m/0/12d/4 private extended key below:

% echo $seed | bx hd-new | bx hd-private -i 0 | bx hd-private -d -i 12 | bx hd-private -i 4
xprv9yimFehUHrTzsGso7fg1yXqzGgAAbYJxubKbgZWzVYvf2tSNcQvbReku1xEiqmoHhhHzRsedx2a4YVQ5qf4TtkdP5DMV7dqhnK1ihKZA5Cj

Different seeds feeding the "bx hd-new" command will yield different xprv* extended private keys.

The $pvt_ext_key above can be converted into a traditional elliptic curve WIF key  below:

% echo $pvt_ext_key | bx hd-to-wif
KzWMQhXEz1Z8s5s16ArUvUEgUmX6rFahacnaMi8HMEUKFDSQ6Pks

The $pvt_ec_WIF_key above can also be directly converted into a Bitcoin address with below:

% echo $pvt_ext_key | bx hd-to-address

1ATcSQCeuQB8xNvCH7XSksNUs8SHU1dfEe