text:
1,500% transaction fee and 3,5 months to confirm?
So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear.
The average btc value of my unspent outputs that come out of the commissions is 100 satoshis (0,000001 btc). That means that if I want to cash out 100 btc, I need to spend on average 100,000,000 of these outputs.
According to: How to calculate transaction size before sending the transaction size is: in*148 + out*34 + 10 plus or minus 'in', which makes my withdrawal equal to: 100,000,000*148 + 2*34 + 10 + 100,000,000 = 14,900,000,078 bytes = 14,9 GB ?! (am I missing something here?)
The maximum block size is 1 MB so I will need to split this transaction in more than 14,900 transactions of 1,000 kB each ?!
A transaction fee of 0.0001 btc per kB is required, so I will need to spend 0,0001 * 1,000 =  0,1 btc for each of these 14,900 transactions which means I will need at least 1,490 btc (to send 100 btc), which is roughly 15 times the amount I'm trying to send!
All these 14,900 transactions will need to be included on different blocks (since they would exceed the maximum block size otherwise) and since one block is found every 10 minutes on average, I will need to wait 14,900 * 10 minutes = 149,000 minutes = 2,483 hours = 103 days = 3 months and a half ?!
Please tell me I got this all wrong. I've really freaked out.
Edit1: Thanks to Nate Eldredge for pointing out an error in the calculations.

If you mine it yourself, you don't need to include fees. You do, however, need to mine 14,900 blocks, which is not so easy (massive understatement).

When you import a paper wallet into Coinbase, do they deduct transaction fees? If not, you could import the private key(s) into Coinbase, and then verifying would be their problem...you'd basically be ripping them off, by exploiting a loophole in their rules. (Warning: if this would work, don't actually do this without Coinbase's written permission. You'd be a jerk, might tank Coinbase and harm Bitcoin with it, and/or get sued.)

Please see what Coinbase's software will do with it :)

You're doing it wrong if your service generates thousands of dust-sized outputs. You need to consolidate your outputs as you go.
I assume that a transaction under your current model is like this:
Input (x1):
Payer Address (X BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (100 satoshis)
Payer Change Address (X - Y - 0.00000001 BTC)

What you should do is to keep the Service Wallet Address accumulate the 100 satoshis as you go:
Inputs (x2):
Payer Address (X BTC)
Service Wallet Address (Z BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (Z + 0.000001 BTC)
Payer Change Address (X - Y - 0.000001 BTC)

The service's commission is always sent to the same address but how does this make any difference, every transaction contributes one more unspent output that is now owned by this address but still are distinct outputs, or am I missing something here?

@Doug: It adds one new output but consumes one that previously existed. The total number of inputs needed is the same, but this way you piggy back on a transaction that is already being made, and don't need to pay another fee.

@NateEldredge could you please analyze this for me on a more technical level? I seem to fail to get it. What you actually say is that if I sent a few satoshis from different transactions to the same local address they will accumulate as a single unspent output?

@Doug to avoid thousands of dust outputs, you must consume your previous output by including it in the TX inputs. So every TX consumes an output at your service address and produces a new output at the same address with slightly higher account balance.

@uminatsu I think I get it! So basically what I do is use my outgoing transactions to mash up my dust outputs into a single unspent output, right? Very smart, thanks for making it clear for me, also thanks to Nate.

As amended, your calculations look essentially correct to me.
(The total time will actually be worse, since you are competing with all other users of the network for block chain space.  And some miners enforce a smaller block size limit - in the default client I think it is 350K.)
So I suggest that you don't do that :-) As far as I know, Bitcoin was never intended to be used for micro-payments like this, and in fact many of these features exist specifically to discourage them. You may need a different business model.

You will need to start a policy of merging these transactions together, small group by small group. You will have to investigate the optimal strategy for it.
Then, over the course of probably years, you will have to keep these dust-mopping-transactions filling out the free crannies and nookies of every block. You'll be done in O(nlogn) transactions.
This result is somewhat intentional, it is a massive administrative pain to have all these mini-outputs. From now on you may wish to either bundle transactions (as to have less dust) or continuously mop dust together. It's a shame though, super small transactions are a neat feature!


text:
Transaction's maximum size
Is there a maximum size for any given transaction?
I just created this tx:
http://blockexplorer.com/testnet/tx/194173dcc07b396433d5725abe76d52b10d42ebd3d1d10b465429f87fee12a52
and although it seems to get confirmed I would like to know if adding more inputs or outputs (and thus increasing its size) could result in an undesired outcome.
Similar question (that doesn't answer my question, though): What is the maximum size of a transaction?

There is a maximum standard transaction size since Bitcoin 0.8.2 of 100k per transaction.
There are a number of other limits that influence the validation and propagation of a transaction though. Specifically:

A block is limited to 20000 signature verifications.
The block itself can't be larger than 1Mb.
The standard Bitcoin client (Bitcoin Core / bitcoind) will refuse to relay transactions flagged as dust.
Enough fee should be included (0.0001 BTC/kb)

Thanks for you answer. Could you please prompt me to the documentation (or source code) of the 200 signature validations limit?

My bad, there is no such transaction checksig limit. It's at the block level. Updated my answer.

links are 404 and reedirect.
First should probably be something like this now but more digging needed. Second might be around here.
Fees are more dynamic now. Wouldn't put an aboslute value but rather this.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Check if wallet is encrypted or not through RPC API
How can one check if their wallet is encrypted through the RPC API without receiving an exception?
I went through the Original Bitcoin client API calls list but didn't find any command that could facilitate this functionality without resulting into an error in the response.
Any ideas or workarounds?

From the source code (rpcprotocol.h):
RPC_WALLET_ERROR                = -4,  // Unspecified problem with wallet (key not found etc.)

So you could check for a JSON-RPC return value of -4, or if you want to be absolutely sure, you can use:
bitcoind [...] -help | grep walletlock

The walletlock RPC command becomes only available (in the -help list) after encrypting your wallet.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How does Multi-Signature Pay 2 Script Hash (P2SH) enable stronger security?
Coinfloor says it will pay out withdrawals using Multi-Signature Pay 2 Script Hash.  What is Multi-Signature Pay 2 Script Hash?  I read What is "Script Hash" address exactly and how does it work? but didn't understand how it enables more secure withdrawals form cold storage.

Multi-signature is a feature to protect against theft.
From securing your wallet

Bitcoin includes a multi-signature feature that allows a transaction
  to require the signature of more than one private key to be spent. It
  is currently only usable for technical users but a greater
  availability for this feature can be expected in the future.
  Multi-signature can, for example, allow an organization to give access
  to its treasury to its members while only allowing a withdrawal if 3
  of 5 members sign the transaction. It can also allow future online
  wallets to share a multi-signature address with their users, so that a
  thief would need to compromise both your computer and the online
  wallet servers in order to steal your funds.

Traditional Bitcoin addresses are secured with a single private key. P2SH addresses can associated with three private keys. Depositing funds into is the same as depositing funds into a standard Bitcoin address. However, withdrawing funds from the address requires at least 2 of the 3 keys to sign.


text:
Transaction broadcasted to the Bitcoin network but not in my mempool
I use armoryd (0.93.1) to send transactions in the testnet Bitcoin network with the three calls:
1. createustxtoaddress
2. signasciitransaction
3. sendasciitransaction
The calls are all successfull, the transaction is broadcasted then mined.
BUT it's never appeared in the mempool !
according to this dicussion : When a transaction is broadcast to the network, what is actually being sent? how is this possible ?!
test realized at 1:42 PM Today

my txId: 814555d2fa93f1f01f84cfadff753cb66594d5fd1205523f82c44ac4da6f5359
bitcoin core mempool: [
      "135ec8b33e79b1a827b474b31460afc6f94104a9d33fea86bf77b38ffcc89bab",
      "3319496f02e377451bc0b27951e488a60a3a4f9dc2c6c5ae3a350e42a0a32d2d",
      "3a1e3674de34013aa45b96d680bd39a29c6ca5b4bcdccdef12dbb03d5a76b72e",
      "4737ec977a4bd256fc9f6250221ea8b935a8c2f0769b62a2e43f9ad685980bef",
      "4d8c4d8f67536007c826de9d2b65a8e566736cba8d80d3c77fe696909624602e",
      "4ec4d33aa4ec6ff136715c5301cc0571220210a417c69479c0bd1a41a6b2a8bb",
      "54a2b0d2e010b1c94f59f5970c882167ad4746c778f23334da4cb9bb9850a203",
      "54e6b52cbbd93efcd33d6f5f38daa538e467401dbd6b1e6ce93f8f9089caf071",
      "75c0765c97805ff6bc7e383d5b927620cf39afa87f061784e94aa092c10c9b57",
      "9c47af29649f2ca07f6203e3b88ab9d723b93cd19c98b9bf8e218306bdfdec15",
      "a982220cc1c6ecd437e1a0f7cd7f99df19b7841c4f1ca4117f57c2e6fd90c153",
      "b3b1a483d9c8151a1bf48b81d4a4aa9193a640078d2e0af0d2b8b8eb673790dc",
      "b6392de0a579a413c224cd379b8d0e6ecd66283fdfd88e1356c8a299200db90a",
      "bd4d9ade8b362548007c0780be1e35a065af9e29ee0ae2f43950b8b192d9865b",
      "c1f02ab8686fc2f678e77ecf4d79cc5f827dd709efd9d3262a66f14b34b8a376",
      "c66958ca3f9a2c526e72a84ac061a5bd31485aa757000badf2049ab386d61054",
      "d2bd27f1c4e42d92781448adada8c7c7c8df701ea23ca66c259c3f4ec90e3f8a",
      "e7c3b7e81cea9cd1d361725c0d0c6bb30f9f63fe882d5d7bd65b12207e13e4ce",
      "ef1838102e2200d73003a147de124bce19efcd98c7334c6f67c97b63f89ff26d"
  ]

This is not a synchro problem no block are mined in the meanwhile. If anyone has a clue..

I haven't used this client. May be a feature in it that it broadcasts raw transaction to a network but does not keep it into mempool because of some reasons, for example low fees? You have to do more tests with sending raw transactions.

Even if armory don't put directly the transaction in the mempool I should receive it from the other nodes, so where is this transaction ?
I'll be more specific, I use armory for a long time now (3 months and more than 500 transactions) and check automatically the bitcoin mempool for the transactions I send because sometimes armory mess up with the transaction broadcast. This behaviour is new and I can reproduct it.

Your peers should not send transaction back to you, even notify you about it because they assume that you have it already :)

Ok.. any clue of how I can get this transaction back in my mempool ?

Confirmed in block transaction should not exist in mempool. You have to do more tests. I can not answer your question, just speculating

I know I want it back before the first block ;)
I'll investigate more, if anything comes out I'll notify it here.


text:
Bitcoin resistance against forged slow chain
I'm implementing a new protocol with a custom blockchain, and I'm trying to figure out what is the correct way to deal with the "slow chain" problem.
In the Bitcoin protocol, nodes constantly gossip the newest block and try to produce a block after it. However, it sometimes happens that concurrent branches emerge, and from time to time nodes have to perform a rollback, 2 or 3 blocks into the past.
As we know, block difficulty depends on the time differences between blocks. A malicious entity can easily forge a chain of arbitrarily many blocks by simply starting from the genesis block and producing blocks with consecutive timestamps differing by more than 10 minutes. This way the difficulty would never increase, and the chain can be produced cheaply.
Of course, as a result of this approach, timestamps in the forged chain would increase much faster than in the real chain. This would cause the forged chain to be discarded by nodes, as legal blocks must have timestamps less than or equal to current timestamp (plus/minus some tolerance).
But the problem is:
Alice controls a bitcoin node, and has 500,000 blocks in storage. Bob advertises that he has 600,000 blocks, but the last common ancestor has number 1000. Bob's chain is a forged slow chain, but Alice does not know it. Alice wants to download Bob's blocks and check if these are correct.
QUESTION: How can Alice detect that Bob's chain is invalid before actually storing it?
Approach 1: A downloads all blocks after the last common ancestor with B, checks if everything is correct, and if all seems to be ok, reverts storage state by undoing block changes till reaching common ancestor, and then applying newly received blocks.
In our case, Alice would start downloading 599,000 blocks and eventually find out that the timestamp is too big. She would need to store the tentative chain in memory (possibly expensive) and check all the conditions. She would waste a lot of time, and every troll can trick her to do so.
Approach 2: A reverts the storage to the a common ancestor advertised by B, then tries to apply the blocks received from B as they come.
In our case, Alice reverts her storage back to block 1000, applies operations received from Bob, eventually discards a block with illegal timestamp, reverts back to common ancestor, and aplies the blocks she had before communicating with Bob. Again, time and resources wasted.
Approach 3: A can only revert a fixed, small number of blocks in the past. This way, B can do minimal damage, and forging a slow chain is very costly.
But in the case of a long-term network partition (split brain), the network parts would diverge and never achieve consensus on which chain is the longest. This situation would require manually removing records from storage.
Approach 4: A stores all the blocks ever observed, (including abandoned branches), and dynamically keeps track of which branch is the longest. This approach, while safe, requires a lot of storage space and is tricky to implement efficiently.
I'm leaning towards the third approach, but I'm wondering how is this being solved in various bitcoin clients.
I've seen that the core client stores only the longest chain and skips the orphaned blocks. The details of leveldb-based storage are described here:
What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?
Thank you very much for your help.

Of course, as a result of this approach, timestamps in the forged chain would increase much faster than in the real chain. This would cause the forged chain to be discarded by nodes, as legal blocks must have timestamps less than or equal to current timestamp (plus/minus some tolerance).

Not always. For example, in a time warp attack, it's possible to go as many blocks as you want without advancing the clock at all. See How could a time warp attack be prevented? (You should probably avoid making the same off-by-one error in your code.)
For that reason, Bitcoin nodes do not compare chains by their height. (Although they used to do this.) They calculate the total work in each chain (nChainWork), and compare by that. This is calculated by looking at the number of attempts it would take, on average, to find each block, and summing it. This answer touches on how that's done: How is a blockchain split resolved?

Alice controls a bitcoin node, and has 500,000 blocks in storage. Bob advertises that he has 600,000 blocks, but the last common ancestor has number 1000. Bob's chain is a forged slow chain, but Alice does not know it. Alice wants to download Bob's blocks and check if these are correct.

Bitcoin nodes do tell each other how many blocks they each have, but they don't trust this automatically. Rather, they download all of the blocks and check how much work each block has. This can be done faster if you only download the headers; you can tell how much work a block has without downloading the entire block.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How do you redeem a compressed key?
There is very good answer here: How to redeem a basic Tx?
It works great.
But the algorithm is only for uncompressed addresses/keys, how can I change it to deal with compressed ones?
And the second question - how should I change the procedure to redeem several inputs?

Uncompress it? I can't think of why anyone would use lossy compression.

I think it should be a compressed key you want to redeem, not an address. Edited accordingly, please check if I got it right.

Sorry for my poor English. Of course I want to redeem the output to my address taken of compressed-form public-key. This part of question is solved. Now thinking how to put several inputs in one transaction

Exactly the same way, except instead of putting the compressed public key in the redeeming script, you use the compressed one. Decompressing it won't work, as that would change its hash (the address).

Thank you very much. It really works either with compressed keys :) Now I have to sign several inputs and send them to one output. Unfortunately I can not understand how should I change this algorythm - seems to me that I should create several "simplified transactions" with one input and one output, sign them, and after that combine them into one final transaction. I've asked for a help also here: https://bitcointalk.org/index.php?topic=422021.msg4893746#msg4893746

Thank you again. The question is solved. I was able to manually sign two inputs for one output. On testnet of course. http://blockexplorer.com/testnet/tx/c693cccc8f54ec67ff7a1eddf7cb602584e8b20c73be37b025e71b273e8c4adb#i8282342 This one uses uncompressed public keys, but there is no difference


text:
bitcoin payment accidentally sent to Bitcoin-Qt application's sending address
My father accidentally sent a bitcoin payment to his Bitcoin-Qt application's "sending address". Are the bitcoins lost? or is it possible to recover them somehow? When checking on blockchain.info, the funds are visible but I have no idea how to recover them into the Bitcoin-Qt wallet.
I thought it would be visible after his Bitcoin-Qt wallet synchronized but no luck. When referring to "sending address", when you go to sending address in the Bitcoin-Qt client it has one address (you can have multiple) but this was the address he sent the funds to. Unfortunately the bitcoins did not come back to his wallet. This was done 2 days ago. If I look up the same address on blockchain, the exact amount is just sitting there.
Does anyone have a suggestion? Thanks!

There is no difference between sending and receiving addresses. If the address is his, the payment will become visible once his Bitcoin-Qt has synchronized with the network. (Unless with "sending address" you mean an address held by someone else that sent money to him.)


text:
Transaction Questions
Here is a scenario someone posed to me and I'd like to check the answer:

If I send a transaction that gets orphaned and I then issue another transaction from the same address (but include a fee) and this second transaction gets added to the block chain (I have >no reason to see why it wouldn't....there's a good chance other nodes wouldn't even know >about the orphaned block as it may not have been relayed. Can the first transaction be put in a block? When does the transaction get time stamped?
I presumed the answer is that the original transaction will become invalid as it would not be confirmable.  Also, during the orphaned period, the private key could be imported to another >wallet and another transaction issued from that address (AFAIK, no wallet will intentionally >let you construct double spends).

Orphaned is the wrong term for a transaction.  Are you referring to a transaction that was in a block that no longer is in the chain with the greatest height?

Their assumption is correct: if you send a transaction that gets orphaned, and then send another transaction that goes into the block, the other transaction automatically becomes invalid.
Transactions don't have a timestamp embedded, so miners don't have a way of knowing which transaction came first. They just include the one that first reaches them, which in your scenario will be the second one.

But it would depend on how much it was orphaned, correct? If it was temporarily orphaned just because it isn't high enough priority to get space in a block, but had been relayed to miners, then the second transaction would be ignored as a double spend. If it was orphaned because it was so low priority that most clients would not relay it, then the above would apply (and it would be invalid once the second transaction is confirmed). Am I correct?

Yes, that is correct. Miners just build a block based on what they got in their memory, there's not much more to it.

When there are two blocks both at the same height, each can include the same transaction as each doesn't know about the other.
If there are no double spend conflicts the same transaction would generally exist in both sides of a fork, presuming enough nodes were on each side to relay the transaction to miners of each.


text:
Will mining in the (far) future produce a payout?
According to this question, there will only be 21 million bitcoins at most. These coins are being produced logarithmically by mining, so the payout will decrease as time goes by.
When all 21 million bitcoins are in circulation, will there be any reason for mining? Is mining only useful for us "early adopters" or will it be a permanent part of Bitcoin?

@Lohoris Not quite the same question but very helpful. Thanks.

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

Aren't the transaction fees much lower than the current payout of 25 bitcoins? I read that mining is not profitably unless you have powerful GPU's so when the reward is gone, I can't imagine the transaction fees alone will be a good incentive.

@styfle they are now, but once the reward stops being high enough, market should adjust itself: miners would stop accepting low-fee transactions.

@styfle that said, notice http://bitcoin.stackexchange.com/questions/3111/will-bitcoin-suffer-from-a-mining-tragedy-of-the-commons-when-mining-fees-drop-t

@Lohoris I read something about higher transaction fees means the block has higher priority. This might require a new question, but how are transaction fees determined?

@styfle wiki, plus many questions here

The way I understand it, the transaction fee that is automatically recommended by Bitcoin clients is distributed to miners.
That means, that even when there are now Bitcoins left to mine, miners still will earn coins because of the transaction fees. As far as I understand it, miners also serve the purpose to validate transactions and to ensure the integrity of the blockchain, and receive the transaction fees for this.
https://en.bitcoin.it/wiki/FAQ#How_much_will_the_transaction_fee_be.3F


text:
What is "Script Hash" address exactly and how does it work?
I found out this address playing with blockchain
https://blockchain.info/address/3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8
I found out it's something called "scripthash". How does it work exactly? How does it differ from a normal address?
I found out this - https://en.bitcoin.it/wiki/BIP_0016 - but I still don't get it and I don't get the point.

The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.

How does it differ from what is possible today - scanning just the address of the reciever?
edit: And adding one more question - why exactly is this transaction with the mentioned address as input
https://blockchain.info/tx-index/3618498
included in 94 different blocks? How does that even work?

The P2SH, as defined in BIP 16, states that

The purpose of pay-to-script-hash is to move the responsibility for
  supplying the conditions to redeem a transaction from the sender of
  the funds to the redeemer.
The benefit is allowing a sender to fund
  any arbitrary transaction, no matter how complicated, using a
  fixed-length 20-byte hash that is short enough to scan from a QR code
  or easily copied and pasted.

Hence it allows any client implementation to fund a transaction with an arbitrary script, without the client necessarily having to understand it. You see, there are some quite complicated possibilities for transactions to state their claiming conditions, which may put different implementations of clients under a dilemma: each time a new script type surfaces they'd have to implement it so that the client can send transactions that make use of them.
P2SH has the advantage that the client does not necessarily have to know how to build such a script, it just has to know how (given an arbitrary script, or indeed its hash) building a script that first verifies the script and then uses that script to verify the claim itself works.
Suddenly, if I provide you with a hash of a claiming condition (script) you can send me bitcoins without actually having to know what security mechanisms I put in place to secure that only I can then spend them.
As an added bonus it really keeps the addresses small (25 byte script) which can easily be displayed in a QR code or may even be typed by hand.
The reason transaction 4005d6be is included in so many blocks is all of those blocks are orphaned, so the miners that included them supported a version of P2SH but never got a majority. The fact that this transaction is still unconfirmed is probably due to it being not a true P2SH script.

Oh! Amazing. Another question: How much is P2SH supported today? What all can I write to the encoded script? I found out that miners won't accept any arbitrary script, is the same thing true about the encoded scripts?

That's a good question. While you can specify a hash of an arbitrary script to be a claiming condition we have to make sure that the script is valid, otherwise you won't be able to spend those coins ever again.

@cdecker could you elaborate on that second paragraph of yours that begins "P2SH has the advantage that..."? Is the client the one sending the bitcoins, or the redeemer? Can you give an example of what type of script they wouldn't have to build, and then also give an example of the script that verifies the first script?

Let's say the sender has a really old wallet, that does not support multisig addresses. Using P2SH the receiver creates the hash of a script that does multisig, uses it to create a P2SH address and sends it to the sender. The sender now has an address, which is a valid P2SH address, and can send funds to it, even though it does not know anything about multisig addresses. For an example I'd like to point you to the examples in BIP 16.

You said a "client does not necessarily have to know how to build such a script".  If I use a beta wallet that uses P2SH addresses, and they make a mistake where the script is miscalculated and can't spend the funds... or is it more foolproof than that and I'm needlessly paranoid?

Well that comes down to how much you trust the wallet you as a recipient are using :-) It's similar to your P2PKH wallet having a mistake in the hash computation, or it using the wrong pubkey, or it deriving the pubkey wrongly from the privkey. That being said, wallets are thoroughly tested before being released, so I wouldn't worry too much if you use a well tested wallet implementation

@cdecker hi, I am also programmer, I have talk to you about making crypto currency. What is your contact? or send me email  [ wsxdrfv (at) hanmail (dot) net ] Thanks.

I recall some of these transactions and researched them.
P2SH was introduced as a soft-fork, meaning old nodes technically didn't have to upgrade - the soft fork could be carried out by a hashrate majority of miners.
OP_HASH160 [20 byte hash] OP_EQUAL
This is the P2SH scriptPubKey. Before the soft-fork, it meant that anyone that knew the value that hashed to [20 byte hash] could spend the coins.
A quick note on hashrate-majority enforced soft-forks. These are normally invisible to clients unaware of them. The reason is, these soft-forks usually only forbid certain things from happening, rather than allow something new and unexpected to happen.
P2SH is one of these types, because it added further rules to the above snippet of Bitcoin Script. The rule is, if the value hashes to [20 byte hash], then assume it is a string of bitcoin script and verify it. All this does is prevent some spend attempts from entering the blockchain - they might fail P2SH validation.
From an old version's point of view, if something you allow never happens again, there is no rule violation.
So, why was this block 'mined' 94 times? Well, partially because Blockchain.info uses confusing terminology. They received 94 blocks including this transaction. It's just a pity they were all orphaned!
This is an unfortunate case where the hashrate-majority soft-fork actually caused problems for someone. That someone was in the minority running v0.6, and kept running the older software version (or they forgot to upgrade). Their software a transaction with a valid pre-image for [20 byte hash], and accepted it into the mempool. It then tried to mine it.
The majority, however, had just accepted a rule where such transactions are exposed to additional validation, and deemed this transaction invalid, so they refused to build on top of these blocks.
Regarding P2SH addresses, they are very useful these days. You can request someone to fund a complicated script (like multisig, or a Lightning channel) using a fixed-size address!

Is segwit not a hashrate-majority enforced soft-fork? I can't understand how it is only forbidding and not allowing something new.

Right now you can pay to OP_0 [32 bytes] and miners would put your spend in a block without you providing a signature. (though, we wouldn't softfork that script if someone was using it)
With segwit activating, outputs with this script are no longer accepted without scrutiny - the new rules are applied (must provide a VALID witness now), so that only non-rule violations are included in blocks.
To old nodes, there is nothing new happening. Just the absence of something it didn't care about.

Same as P2SH - old nodes who would have accepted spends of OP_HASH160 [HASH] OP_EQUAL before activation would accept any transaction with no signature. Afterwards, they wouldn't realize that all the signatures which would fail P2SH evaluation aren't around anymore.

Going to be lolz epic when all the SegWit transactions are double-spent, i.e. stolen by miners on The Real Bitcoin (the legacy Satoshi blockchain).

Please follow our "Be Nice" policy, that's not an appropriate way to address people

I want to know more about segwit. And soft fork, hard fork differences, meaning. Eventually, how to apply them from programmer point of view.

Segwit is in some ways similar to P2SH if you compare them. Look at the reference code. Your other questions probably warrant a separate question :)


text:
Which BIP-148 branch is the most recommended?
I want to run an BIP-148 ("segwit UASF") node. However, I am not sure which of the various branches is most maintained and recommended to run.

There is this pull request by earonesty (386 commits behind master, last commit May 30)
There is a different pull request by earonesty (on luke-jr repo, 154 commits behind master, last commit June 22)
There is also UASF/bitcoin repo (1379 commits behind master, last commit July 2)

Which of these repos is the most recommended one?
(Note: this question might get outdated soon. For reference, I am asking it 3rd July 2017.)

As luke-jr (author of the code in one of the PRs) said in the comments right now, the branch is abandoned and the recommended code is in UASF/bitcoin repo.
(Again the answer might get outdated soon.)


text:
Trying to send Bitcoins from testnet to my regtest node

I send bitcoin regtest server BTC to other bitcoin address of same server. I sent 5 BTC but it shows 50 BTC of that account's associated address. It received 5 BTC.
What's the problem with this account or address?

I used https://tpfaucet.appspot.com/ to get free BTC for regtest server address. I send BTC to many of my addresses but I didn't receive any amount on account associated addresses.
What's the problem on this server or regtest bitcoin?

The regtest system is completely isolated from testnet and only exists on your local machine by default, you won't see the transaction from TPs faucet because it isn't on the same network. Blocks in your regtest setup can be instantly created using bitcoin-cli setgenerate true <number of blocks> each of which will bring into existence 50 BTC in your local wallet for testing with.

what is the port for testnet server?? how to i confirm the regtest server transaction ???

Regtest is 18444, testnet is 18333

http://bitcoin.stackexchange.com/questions/39073/how-to-use-bitcoind-jsonrpc-for-regtest-or-testnet-server-in-php please see link answer. here write
Regtest is 18332

That would be the RPC port shared by regtest and testnet, yes.

how to i confirm the regtest server transaction ???

@ShahadatHossain: confirmation works by mining a block. In regtest you can min a block with bitcoin-cli --regtest generate 1

I need to confirm my transaction not to generate block. I already run this and get 50btc. but i could not confirm transaction send or received. please if any idea comment here

@ShahadatHossain You don't generate blocks with testnet, miners do, just like the Mainnet. I now see your problem with receiving TP Faucet testnet coins, check your question for my answer.


text:
Setup a private bitcoin network
This question is similar to previosuly asked question Start a Private Bitcoin Network but since I can't comment there I am asking again.
I am working on a concept specifically for existing bitcoin so the suggested methods of litecoin or regtest are not applicable for my purpose. I need to simulate a bitcoin network over my LAN/Wifi and it would be great if someone could point me towards a method to do it.

Why won't your own regtest work?

it can simulate only one node on a machine locally, right ?

Actually, no, you can use multiple machines on a regtest network, you just have to manually connect them using addnode. See the docs.

@StephenM347 thanks that works perfectly. However, I have another concern, since DNS seeding and Fixed seeds are disabled in regtest mode, how can I simulate at least one of them so as to simulate a complete bitcoin network with peer discovery on my network ?

I've added a more modern answer to https://bitcoin.stackexchange.com/q/36341/101498, i think it answers your question here too (TL;DR use Signet) and it can be closed as a duplicate.

Does this answer your question? Start a Private Bitcoin Network


text:
Migration from Berkeley DB to LevelDB
In 2013 a new bitcoin core was released and one of the supposed improvement was migrating from Berkeley DB to LevelDB. According to the release notes at bitcoin.org:

LevelDB, a fast, open-source, non-relational database from Google, is
  now used to store transaction and block indices. LevelDB works much
  better on machines with slow I/O and is faster in general.

Similar statements were done by bitcoin core developers:

LevelDB - an open-source rewrite of Google's own database system - was
  designed for efficiency and consistency on commodity hardware, and
  outperforms BDB by an order of magnitude in some settings. Preliminary
  tests with LevelDB show very good results.

However, nowadays there are several comments through the internet critizing LevelDB. According to LevelDB page at Wikipedia:

LevelDB is widely noted for being unreliable and databases it manages
  are prone to corruption. Academic studies of past versions of LevelDB
  have found that, under some file systems, the data stored in those
  versions of LevelDB might become inconsistent after a system crash or
  power failure. LevelDB corruption is so commonplace that corruption
  detection has to be built in to applications that use it.

In summary, the complaints about LevelDB are:

unreliable and databases are prone to corruption
several bugs due to fundamental flaws
poor code quality
no longer actively maintained (i.e. dead project)

Question 1
Are these complaints about LevelDB correct?
Question 2
What is the final balance of migrating Bitcoin Core from Berkeley DB to LevelDB? Is LevelDB working as expected? This migration was the right choice?

IIRC, Bitcoin uses BerkleyDB 4.8 for wallet files, and LevelDB for blockchain indexes. Informally, I can tell you that blockchain index corruption during crashes is very common, and I usually tell affected users to redownload the blockchain.

@NickODell Do you know whether such crashes you`ve mentioned also happened before the migration to LevelDB?

Sorry, I don't know.

@NickODell, should I backup my Bitcoin Core data directory (eg. chainstate/ and blocks/) so that I wouldn't have to redownload the blockchain from block 0, in the event of LevelDB corruption?

As someone who was involved in doing that migration at the time, I believe it was the right decision. LevelDB is far from perfect, but I wouldn't know what else to use.
In particular:

BDB is much slower for our usage (large atomic batch writes, small random reads).
There were reports of database corruption as well with BDB, at a time when it was used far less intensively than LevelDB is now.
BDB is very painful to upgrade. My impression is that it was designed for setups where a database upgrade only happened with professional supervision. In particular, the write log files created for durability were sometimes not readable by later versions. This is the reason why Bitcoin Core releases have for years stuck with BDB 4.8 for the wallet.
BDB has many resource limits that need configuration, where inappropriately chosen values may cause network-wide failures (read up on the March 2013 incident, specifically). The official documentation on this states Reviewing the Lock subsystem statistics is the best way to determine this value. I believe that's not acceptable for our use case.

While database corruptions are reported relatively frequently these days, my belief is that it's mostly hardware failures or driver issues. Bitcoin Core tends to stress disks, memory and CPUs far more than most software, which makes otherwise invisible issues pop up.

> "[...] database corruptions are reported relatively frequently these days [...]" Is there an active LevelDB community to provide some feedback/support about such issue?

I personally never see corruptions, but I run on relatively new hardware, and use Linux. But I probably resync the chain on average once I week for development purposes. That doesn't mean I don't believe such reports are real, but at least in some cases they turn out to be due to flaky hardware or storage systems - in which case it's hard to blame the database software.

What about Redis? https://db-engines.com/en/system/LevelDB%3BOracle+Berkeley+DB%3BRedis


text:
Offline wallet for blockchain.info
With the removal of the feature to import ages.json files to MultiBit in 5.18, are there any other ways to take my backup and access my bitcoins in the event BlockChain.info ever dies?
Edit: Just saw this question which partly answers my question, but I would still like to know if MultiBit is the only client that can read these files.
Thanks in advance for the help

The code you need should all be at https://github.com/blockchain/My-Wallet. I don't know if anyone's made a tool besides MultiBit that can read it, but as long as people have that source available (you can make a copy of it if you like), someone will be able to either use that JS directly, or write an equivalent app that can convert encrypted aes.json files to unencrypted private keys for import anywhere.

So probably no. Ok, write that an an answer? There seems be a lack of good accepted answers here, gotta fix that :-) good to see its open source.

Blockchain.info's wallet is based on the code at https://github.com/blockchain/My-Wallet. (no license is specified that I can see, but it seems apparent that they wish you to have the right to use it to own your keys) But let's take the worst-case view we can regarding this: Blockchain.info is suddenly offline, and their My-Wallet code with all of its forks on github are removed. You have a backup (encrypted or double-encrypted) and you wish to restore it.
pinheadmz has created an open source blockchain.info wallet decryption tool, based on a tool that blockchain.info has temporarily removed.
I have downloaded the existing Import Wallet page and tweaked it to dump the private keys in an alert window. This works with all of the encryption schemes that blockchain.info currently supports. It's quite unpolished, but does the job. It outputs each private key in the format in the backup (usually base58, which is somewhat unusual) and hex. You can download it at this link.
To ensure that you can easily make use of the above output, you might also want to have an offline copy of the (open source, public domain) Brainwallet site, which I've made a copy of here.
You and I are hardly the only ones to think of such things. This thread offers some good tips on using your Blockchain private keys offline (e.g. enable the option for automatic backups to be emailed to you when your wallet changes). I think it's quite safe to say that (as long as you have a good backup and know the password(s)), with a little help from the Bitcoin community, you will always be able to recover your Blockchain.info private keys for use elsewhere.

well researched, detailed and extreamly helpful. thank you


text:
Do all Bitcoin alternatives need to have a coin limit?
In the Netherlands, it was just in the news the e-gulden was launched.
Before we got the Euro (€) we had that currency in our country.
An E-gulden (EFL) is currently 50 EFL = €1,50
But is there for any cryptocurrenty a limit? Or could the creators just create as many as they like?
I know that Bitcoin has a maximum coin limit.

E-Gulden has a limit of 21 Million.
Most, but not all cryptos have a limit, for example DogeCoin recently announced that there would be a minimum reward of 10,000 doge for every block after the previously announced reward schedule was supposed to end.

The idea of having a max limit is that inflation is considered bad by most of bitcoin/altcoin developers and users.
With non digital money, you need to add more coins, because the population will increase and you will need more coins to show the wealth difference between those humans. There is also the fact that governments (or those that influence it) somehow like inflation.
With digital money you don't need this. because you can just add a 0 before a number. If the max coin amount is 100 and you need more coins, you just allow people to trade 0.1 coins, and then alow then to trade 0.01 coins and then 0.001 coins and this goes on and on. This is impossible with real money, to add 0.001 dollar coins you need to put them at the market, with digital currency you just allow people to split their "0.01 dollars" into 10 parts of 0.001 dollars.
There is also the fact that you can just ask for transaction fees, or include demurrage where people lost X dollars (or X% of their money) every Y months. This you will have coins to give to miners even after all the coins were mined.

Nope, they aren't required to have a limit. The Bitcoin wiki explains why a coin cap is useful.
But an important thing here is that they aren't required to have a coin cap. There is no authority dictating what an altcoin can and can't do. Right now you can go out and create a coin with any feature you want, maybe it won't be viable but it is up to you.
On a quick search I found that Liquidcoin has a minimum of 1 coin per block. Meaning that over an infinite time span the amount of Liquidcoins in existence is infinite.

Developers who make altcoins tend to edit the maximum amount of coins that can be mined. Typically when an altcoin is announced on bitcointalk.org, one of the "specs" or selling points for the coin is how many possible coins can be created. If anyone is interested, I can find in the source code for various altcoins where this limit is set (reply to the comment with interest and I'll go look). I can also compile a quick list of altcoin announcements where the max amount of coins are stated.
Its also possible that a limit is originally set, but then the devs/maintainers of the coin will modify the source to change the limit - I believe something like this happened with dogecoin for example. And I believe the term is called a "hardfork" where they modify the coin source and tell everyone to upgrade to the new version which imposes the new changes such as max coin limit.


text:
What is the best method of getting the originating address of Bitcoin transaction?
As far as I see there are currently two methods of getting the sender's address in a Bitcoin transaction:

Look up the input transaction and read the corresponding output address there (like this: How to findout the sender of a transaction)
Convert the public key in the scriptSig to the address (like this: Why does gettransaction report me only the receiving address?)

Is one of those preferable over the other one?

Normally, senders aren't even aware of which address(es) they might be using for sending. Some wallet software may allow advanced users to specifically choose which sending address to use, but this is not normal. What information do you hope to discover using the sending address?

@GregHewgill I'm thinking about online services which return the Bitcoins to the originating address, e.g. SatoshiDice.

"Originating address" is not a valid concept in Bitcoin.
Some sites (like Satoshi Dice) try to make an educated guess but they might as well be throwing darts blindfolded.
The only safe way to refund Bitcoins is to explicitly obtain a refunds address from whomever you're accepting a payment from.
Anything else you do is going to break sooner or later when a customer pays you via a type of wallet or transaction which you weren't anticipating.
"Break" here means sending funds to the wrong entity, or even worse: permanently losing them by sending to an address for which no private key exists.

In addition, building infrastructure that assumes a "from address" can be guessed will hurt the ecosystem by making new features which break that assumption harder to deploy (contracts, complex transaction types, script upgrades, coinjoin, ...).

scriptSig contains a public key that belongs the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value.
So you want to check the referenced output if you're looking for the originating address.


text:
Previous block hash on first Bitcoin block?
The bitcoin-explorer command bx fetch-header -t 1 fetches the first Bitcoin block and shows the block header.
If I check the "first" block header, where does "previous block hash" come from?

Found the solution, the command for the genesis block should be:
bx fetch-header -t 0


text:
cannotsend error using python bitcoin library to send bitcoin on testnet
When I run the script
from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc

rpc = bitcoin.rpc.Proxy()
addr = bitcoin.wallet.CBitcoinAddress('mfrMeTKojpEXFXpcQiRr7zA3Bff4UBgZTx')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

I get the following ERROR
CannotSendRequest                         Traceback (most recent call last)
<ipython-input-23-904d1d3102d7> in <module>()
----> 1 txid = rpc.sendtoaddress(addr, 0.001 * COIN)

/home/remote_user/unix_practice/python-bitcoinlib/bitcoin/rpc.py in sendtoaddress(self, addr, amount)
    557         addr = str(addr)
    558         amount = float(amount)/COIN
--> 559         r = self._call('sendtoaddress', addr, amount)
    560         return lx(r)
    561

/home/remote_user/unix_practice/python-bitcoinlib/bitcoin/rpc.py in _call(self, service_name, *args)
    150                              'User-Agent': DEFAULT_USER_AGENT,
    151                              'Authorization': self.__auth_header,
--> 152                              'Content-type': 'application/json'})
    153
    154         response = self._get_response()

/usr/lib64/python2.7/httplib.pyc in request(self, method, url, body, headers)
    971     def request(self, method, url, body=None, headers={}):
    972         """Send a complete request to the server."""
--> 973         self._send_request(method, url, body, headers)
    974
    975     def _set_content_length(self, body):

/usr/lib64/python2.7/httplib.pyc in _send_request(self, method, url, body, headers)
    999             skips['skip_accept_encoding'] = 1
   1000
-> 1001         self.putrequest(method, url, **skips)
   1002
   1003         if body is not None and 'content-length' not in header_names:

/usr/lib64/python2.7/httplib.pyc in putrequest(self, method, url, skip_host, skip_accept_encoding)
    869             self.__state = _CS_REQ_STARTED
    870         else:
--> 871             raise CannotSendRequest()
    872
    873         # Save the method we use, we need it later in the response phase

CannotSendRequest:

Any idea how to resolve this? I used the code from
Sample Post

If you find an answer especially helpful in solving your problem, you should click the checkmark button next to it to indicate so. Please don't post answers to thank other users, accepting the answer is sufficient.

The issue was that addr is being provided an invalid address - a Main Net address does not work on Test Net, and vice versa.  (From the edit revisions history, the code sample you provided was using bitcoin.wallet.CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T') which would provide a Main Net address)
Replace the address being supplied in the addr variable with a legitimate Test Net address, and it should work.

The code works. Thanks to @Thoamas Ward for pointing out the mistake

@ThomasWard Can you explain what does this command do? I am not able to find documentation that explains it well
addr = bitcoin.wallet.CBitcoinAddress('mfrMeTKojpEXFXpcQiRr7zA3Bff4UBgZTx')


text:
Can I lower fees with stratagy
Say I have two accounts in my wallet. Account A has one address, account B though has 5 address. Each address in account B has a dust amount of coin in it. If I were to use the rpc 'move' command, moving each piece of dust from the respective address in account B over to one lump in account A

Accounts, exist only within the Bitcoin Core client. They are just a bookkeeping device to group your funds. You can move coins between accounts with the move command in the Bitcoin Core console. This updates the client's internal records to adjust the balances of those accounts, but doesn't actually cause any coins to move between addresses, so it has no fee.

How is that valid, as account A would have the one primary address? Does this mean that I am sending to another account owned by me so the coin dust is landing in the account ignoring the primary address?
And say for example I then used the lump in account A to buy some new boots. Wouldn't that make the next fee that account A would pay higher as it was made from a collection of dust(s)?
Would I have to wait a considerable amount of time to lower the fee? Is there another strategy I could use to bring the fee down? Like importing an external key from an compressed pubkey from another wallet (C), paying to to C from A. I don't yet fully understand public keys and compression but as I understand sending to them is considerably cheaper (something to do with inputs?.. not too sure what exactly those are)
I feel sort of like I am understanding more, can someone please clarify a little and/or correct me?
Edit-1
What if I wait a while then as Tim S suggests... Account B has 5 addresses, lets look at one of them (an address with piece of dust in it). Lets say that some more dust payments were sent to that address making the 'dust pile' grow.
At what point is it not dusty?
Are there still too many inputs?
(Am I confused by the term 'inputs': "inputs from many addresses in your wallet" or "inputs from many payments to the one address")
Say I waited 3 days after all the dust came in and settled until it gained priority, then sent the whole dust pile (from that account B address only) to another address. Would it be more worth sending / have I made the situation better?

Regardless of what accounts they are in in your wallet, consolidating/spending your dust may require substantial transaction fees - maybe even exceeding the value of the dust. The major factor that comes into play is the size added to a transaction by each additional input. You can read a lot of info on the Bitcoin wiki about transaction fees.
Here are some strategies for reducing/eliminating the fees:

Include some dust in a free transaction. How much you'll be able to include without lowering your priority below the minimum for a free transaction depends on the coin-age you're spending in the transaction (large, old balance = high priority).
Include some dust in a paid transaction. The 0.0001 BTC per thousand bytes means that if you have a transaction that's only, say, 250 bytes you can add up to 750 bytes of extra data (in this case, dust inputs) for no additional cost.
Transmit your transactions directly to a free transaction relay/low-fee pool. For example, Eligius only requires 0.1 TBC (0.00004096 BTC) per 512 bytes.
Wait it out. If the value of a bitcoin rises substantially, the transaction fee limits will likely be lowered to account for that, so your dust will not be so dusty-looking.

If these all sound like a bit of a pain, that's because Bitcoin isn't really designed for micro-transactions, and much is in place to discourage spamming in the form of "dust".

This is because of too many inputs? If this is true then all leftover dust is un-usable (true or false)?

Inputs add size to a transaction. Size adds cost (to prevent spam from overwhelming the network). If you're looking for a true/false answer then, definitely false. It's not completely unusable. But practically, it might not be worth the trouble.

So what if I do wait a while... please see edit-1 to my question


text:
Question about pool hashrate
Actually I am working with some small academic project right now and I am newbie in crypto currencies. This project is primitive mining pool for cryptocurrency, as a base cryptocurrency I am using dogecoin (don't ask why, i just liked the name). I've read a lot of information, looks through lots of projects and actually I've created it. So I could connect with the mining tool to my pool right now and start to mine. if I made everything correct I am sending difficulty=1 to client via stratum protocol and start to mine. The process looks fine and soon clients begin to submit lots of shares so I get some shares for difficulty 1. I need to calculate (my average hash rate for example for last hour) of the pool according to the shares amount I've get. I take a look to this page: https://en.bitcoin.it/wiki/Difficulty And I got two questions.
1) I've found that I need to calculate avg 4,294,967,296 hashes for difficulty 1 but as I've found my clients generate much less hashes (according to the mining tools info it's about 30khash/s in common) but they still sends lots of valid shares to server. So actually I can't understand - is that ok, that several desktop PC could generate a lot of shares for difficulty 1.
2) I can't understand the hashrate calculating algorithm. My final goal right now is to calculating of pool avg hashrate based on shares count, and difficulty which i send to my clients. I take a look to this What is the correct algorithm to calculate worker & pool hashrate and try to calculate hash rate according to my last hour of testing. Server got 120 new shares from miners its results in 143,165,576/s (143 mHashes) but the minners tools show other numbers.
Thanks in advance.

Most likely, you are considering 2^16 to be difficulty 1, not 2^32. 2^32 is a common base for SHA256d coins like Bitcoin. 2^16 is common for scrypt coins like Dogecoin.

Thx a lot, 2^16 is looks fine. There are really not so much info about SCRYPT. Thx.


text:
Where is bitcoin-qt's blockchain stored in Windows 7?
I need to manually resync from scratch due to a database corruption caused by windows auto-rebooting.
Where is the blockchain stored so I can delete it (and hopefuly prompt bitcoin qt from creating a new one)?
see Bitcoin QT error. How can I prevent corruption of database?

Start your client with the -reindex command-line option. This will cause the database to be wiped and rebuilt from scratch.
To answer your actual question: see the Data directory entry on the Bitcoin wiki.


text:
what is the bitcoin.conf for testnet3?
I need to use bitcoin testnet3 server for testing via php.

bitcoin.conf
rpcuser=bitcoinrpc
rpcpassword=random string
testnet=1
create JsonRpc object with easy bitcoin:
$bitcoin = new Bitcoin('bitcoinrpc', 'random string', 'localhost', 18332);

what is the solution for this? does rpc port is right for tesnet3 server?

Yeah, that all looks fine. Are you having a problem with it?

@NickODell I thought Bitcoind/cli was disabled without the the daemon/server flags?

note: mainnet and testnet rpcpassword are same


text:
how to get confirmed balance for bitcoin testnet server?
I can't get confirmed BTC from https://tpfaucet.appspot.com/ server.
Tried many address and can't get balance with confirmation. for that reason my testnet server balance is always 0.0

bitcoin.conf
rpcuser=bitcoinrpc
rpcpassword=random string
testnet=1
address get by getnewaddress:myVwyA9ooffVDqvbRJC4Kmspu2rDJBacTk
i used https://www.blocktrail.com/tBTC for know about my transaction and it's said it unconfirmed.

For that reason I am not able to test my server purpose.
what should I do now???

This looks a lot like your previous question, http://bitcoin.stackexchange.com/questions/39083/testnet-server-wont-get-any-btc-from-tps-testnet-faucet-what-is-the-reason, and there's no indication that you've tried any of the things that Wizard Of Ozzie suggested. All that we know is that it doesn't work. This is not very helpful for debugging.

it's not duplicate. I have edit the definition of body.  @NickODell


text:
how to calculate transaction bytes of a x BTC? x=0.2
i have read : How to calculate transaction size before sending
but i will not understand what are in and out.
as describe in this link in=40 and out=16
what does it mean???
i will send only one address to 0.20BTC of 1BTC account.
please describe this transaction size.

This question is pretty hard to understand languagewise, could somebody that understood its intent please improve it and properly tag it?

Usually, you want to do this to estimate a fee before sending a transaction. Transaction fees are way more complicated than they probably should be. I'll stick to calculating the transaction size here, but keep in mind there's more to the picture when talking about fees.
in is the number of inputs, and out is the number of outputs. If you haven't seen this discussed before, here's a crash course.
Using a block explorer you may have noticed that some transactions use multiple inputs, even though only one address is spent from. For example:
https://blockchain.info/tx/52a3f2ba48598da7359cfa5d7419848d358f8739aa47bcbe36413bdcb77e9194
Bitcoin is an "electronic cash system". Understanding this concept is probably the most important thing you can do as a Bitcoin user. Unfortunately, it's the part that most beginning users skip.
Rather than physical tokens like metal coins and paper banknotes, Bitcoin uses electronic tokens. There's more here: Bitcoin: Think of It as Electronic Cash.
In Bitcoin, there's a useful relationship:
coin ≈ unspent output
Think of a transaction as a box. On the left are inputs. On the right are outputs. Each input links to the output of a previous transaction. An output can only be spent once, and it must be completely spent. An output with no later links to it can be spent, and is often referred to as an "unspent coin".

Each input in a simple Alice-Pays-Bob transaction contributes ~180 bytes, if you're using uncompressed public keys, and ~148 bytes if your public keys are compressed.
So, to estimate the size of the transaction in bytes, you need to know how many coins will be spent, and whether your public key is compressed or uncompressed.
Unfortunately, "consumer friendly" wallets won't show you your coins. You'll have to use a more advanced tool that supports "coin control" to do that. Bitcoin Core and Armory support coin control, as does Electrum to a limited extent.

In the simplest typical case, you'll have one input and two outputs (the recipient, and change). So in=1 and out=2. According to the linked formula, the transaction size will be about 160+2*34+10 = 258 bytes. It does not depend on how many bitcoins you are sending.
However, if the money you are sending came from many different sources, you will have many inputs and the transaction will be bigger. Again, this does not depend on the amount of money, but on the complexity of your wallet's history.

in  =1times  = .2btc out=2times = 0.8btc and 0.2btc . is it right?? what is my transaction fee for that??? sorry for disturbing you.. thank you

Usually a fee of 0.0001 bitcoin will get your transaction confirmed quickly.

i transaction many type of amount. but a amount .0002BTC i do transaction many times, it fees as 0.00012568, 0.00015528 BTC, 0.00012096 BTC. how can i calculate this value???

@ShahadatHossain: I don't know.


text:
Not possible to load the blockchain in multibit so can't pay or recieve either till it's loaded
"C:\Users\Pompen\AppData\Roaming\MultiBit".
 "C:\Program Files\MultiBit-0.5.18".
Unable to load blockchain "C:\Users\Pompen\AppData\Roaming\MultiBit\multibit.spvchain". The error was "com.google.bitcoin.store.BlockStoreException Corrupted block store: could not find chain head: 0000000000000000139072ad82693ddc93b29fca541778907aced232b031072b".
Opening wallet "C:\Users\Pompen\AppData\Roaming\MultiBit\multibit.wallet"...
... done
Opening wallet "C:\Users\Pompen\AppData\Roaming\MultiBit\Naamloos.wallet"...
... done

Then it shows these messages:

Starting blockchain replay from network...
Replaying blockchain from date "7-May-2015"
Stopping Bitcoin network connection...

And this error:
**17:56:34.604 [SwingWorker-pool-2-thread-2] ERROR org.multibit.network.ReplayManager - Cannot download blockchain as there is no PeerGroup**

Have a read of this support note on multibit.org which looks like it covers that error:
https://multibit.org/en/help/v0.5/help_support_blockStoreException.html

BlockStoreException
You see a BlockStoreException very occasionally when MultiBit starts. It prevents you synchronising with the Bitcoin network.
You can fix this problem by doing the following:

Find where MultiBit is storing your user data - see the help topic Troubleshooting

Shut down MultiBit

Go to your MultiBit user data directory - worked out in step 1 - and delete the file multibit.spvchain

Start up MultiBit again

It will then regenerate this file and start syncing. After it has synced you should see all your bitcoin in your wallet..


text:
Why am I getting payouts from 6 blocks with only 1 share found with a LTC P2Pool pool?
I was mining in a LTC P2Pool pool and found a share.
As I understand it, if the conditions outlined in this answer would have been satisfied, I should have received a payout from the next block found by the P2Pool network. As a matter of fact, It seems I received a payout from the next six blocks (from 414890 to 415003).
I failed to find the rationale behind this. Could you please enlighten me?

The payout method in p2pool is based on PPLNS. In this method, every share is rewarded for each block found within the next N shares. Depending on the exact value of N and the luck in finding blocks by the pool, this can mean several blocks.


text:
Using a Bitcoin or Litecoin miner for attacking PBKDF2 / SHA-256
I'm wondering if it would be possible to utilize a Bitcoin or Litecoin miner to attack, say, a password database that uses PKBDF2 with HMAC / SHA-256. PBKDF2 uses multiple iterations of a PRF - usually HMAC-SHA1, but sometimes HMAC-SHA-256 - for protecting passwords. The idea is that these calculations have to be performed for each password, so that makes it more difficult for an attacker to test all passwords. The PBKDF2 method is defined in RFC 2898.
Sometimes statements are made that these functions are insecure because of attacks with ASICs and often total amount of Bitcoin SHA-256 hashes is shown as example of what can be done. Now I'm wondering if it would be possible to program a Bitcoin or Litecoin miner to find a password using brute force or a dictionary attack.
Assumptions:

HMAC SHA-256
the salt is known
output of PBKDF2 is 256 bit (the output of the hash) or less
"high" number of iterations, say 4K to 40K

To do this you would have to program HMAC using a single SHA-256. Furthermore, you probably would have to have a method to perform the iterations. The iterations use the same key (derived from the password) for HMAC but the data is dependent on the previous value. Obviously there also needs to be some way to generate or retrieve the candidate passwords.
Would it be possible to reprogram a miner to do this work, or are all the current miners too specialized to perform such operations? Is there a - possibly older - miner that can be reprogrammed to do this work?

Note that this question is about reprogramming/re-utilizing a hardware device. It is not a generic question of using the Bitcoin network to perform cryptographic tasks.

I've added Litecoin to the mix. Litecoin uses scrypt, which is already a Password Based Key Derivation Function in itself, which uses PBKDF2 as underlying PRF (hope that's OK, no answers yet).

@NateEldredge Good link, didn't find that reference. This is however not about the bitcoin network but about specific miners (as in: the hardware device). The answers of the other question seems only valid for the network itself.

Hmm, I just found out about Litecoin by browsing this site. I guess I should probably be looking at Litecoin instead of Bitcoin. scrypt uses PBKDF2 as primitive and asic's seem to be available.

Note carefully the argument you refer to in the second paragraph - it isn't claiming that Bitcoin ASIC miners can be themselves be used to crack SHA-256 passwords, but that they demonstrate that someone could most likely build ASIC SHA-256 crackers with comparable performance at comparable cost (or less).  So security planning should assume that an adversary has access to such hypothetical ASIC crackers.

@NateEldredge Yeah, that's the scary part, because at current speeds many passwords would be a doodle to crack. If you work at THash speeds per device, doing 4K rounds isn't that much anymore. If you could use throwaway miners it would only cost electricity - but that seems to be out of the question.

Would it be possible to reprogram a miner to do this work, or are all the current miners too specialized to perform such operations?

A Bitcoin mining ASIC can only do a single task, mining, it has no ability to do anything further than take an 80 byte header, hash it, and return a nonce if it has a large enough of zero bits. In terms of applicability to general SHA256 computing tasks, it has no relevance whatsoever. They can not do single SHA256, return under any circumstance but a low hash, and can not hash arbitrary data. Scrypt based ASICs do exist, but they are hardcoded to stupidly low parameters nobody would use for password hashing in the real world, the other caveats also apply.

Is there a - possibly older - miner that can be reprogrammed to do this work?

A FPGA can be reprogrammed to do almost any task you take the time to author a bitstream for, it would be possible in some circumstances use FPGA for attacking hashes. The Bitcoin mining FPGA that were used in around 2013 do not have much relevance however, as they were never designed for high bandwidth performance between the host and the chip. You might have been communicating over a 9600 baud serial connection which is too slow to send any significant amount of data across.
GPUs are generally used for this sort of task instead, where you have extremely fast and low latency connections to the CPU and a high degree of concurrency for computing hashes. The efficiency is not as high as dedicated hardware (FPGA or ASIC), but they are commodity devices which can be used for a lot more of these sort of tasks. A high end card can compute in the order of half a billion SHA256 hashes a second when the input is only several compression rounds long, though it will burn upwards of 400W while doing so.

So, if I understand correctly, hardcoded would be ROM or actual circuits, right? Not EEPROM, flash or other stuff that can be updated using firmware.

An ASIC is literally transistors etched into silicon.

OK, that's clear, I was just unsure about the level of the interface. I presume even the ASIC's have some kind of CPU that performs distribution tasks, etc. I was not sure about the actual functionality of the ASIC itself. If it can only do scrypt with the parameters for Litecoin then the search ends. If you can confirm this then I will accept the answer. Note that brute force password generation would not require much CPU power and could possibly be performed locally.

There's no processor on board to speak of, there's registers that take input over a serial interface, and hundreds of hashing cores in each chip which do the actual hashing, they either return a nonce, or a request for new data to hash depending on which outcome they have. In fully built machines a small computer serves work to the chips, of which there might be hundreds in total. On the chip surface, each of the pink squares is SHA256 laid out in discrete transistors. http://s.zeptobars.ru/bitfury-Si-HD.jpg A hashing board filled with chips, waiting for work. https://i.imgur.com/6CJAhwv.jpg

Ah super, that fully clarifies any doubt that I had. The first picture would be an interesting addition to the answer by the way. I'll have to buy a new tower rig with graphics cards it seems if I want to perform some white-hat research with regards to hashing passwords.


text:
Is there actual consensus on the blockchain's tip or only until the next block?
Using this scenario https://bitcoin.stackexchange.com/a/40435

Let's say we have two competing blockchain tips: They both start from
  Block A as a parent, but then there are two different blocks found at
  the same time: Block B1 and Block B2. Both blocks have the same
  difficulty level, and as we learned above this is independent of when
  exactly they were found. Therefore, the total difficulty of Block A +
  Block B1 = Block A + Block B2. One of the two chains will have a
  greater total difficulty once either Block C1 or Block C2 will be
  found.

Is there consensus on the tip being B1 or B2, or only until C1 or C2 is found?  If 2 blockchain explorers have both B1 and B2, can they randomly choose either to be the tip of the blockchain and both would be deemed to be correct?

No, there is no consensus until the next block is found. The network is experiencing a blockchain-fork. It will only mend once one of the tips pulls ahead by adding another block. Then all nodes will reorganize to the longest chain and consensus is reestablished. The losing chain becomes an extinct branch – valid but not part of the longest chain.
There can't be consensus before because from a node's perspective there is no way to tell reliably which one of the two blocks is more popular in the network. They could ask around, but would get mixed answers and could be deceived through a sybil attack anyway. Therefore, nodes accept the first valid block they hear about as the current blockchain tip until proven otherwise – the only valid proof being to be shown a longer chain. They'd still keep the competing block though, and propagate if it is later needed for a reorganization.
In fact, such blockchain forks can even persist for several blocks when competing blocks are found subsequently. E.g. in 2012 there was a blockchain fork with four blocks.
During a blockchain fork, there is a higher risk of doublespends because the competing blocks at same height may confirm different transactions. However, if they occur from natural random chance (instead of an attack), they would be working from the same set of unconfirmed transactions and should contain a mostly matching set. As each blockchain tip considers the other not to be relevant, they do not split transactions to be confirmed, but both try to confirm the whole set.
So, yes. Both are valid blockchain tips, either may turn out to be part of the longest chain in the long run, but a good blockchain explorer should maybe show both until it is clear which one will remain part of the longest chain.

There is no substantial difference between having a block on top or not. Bitcoin does not achieve consensus, ever. Every node makes an individual guess about which chain to accept, and nodes can disagree for arbitrarily long times. The more blocks on top, the better that guess is, but it always remains a guess.

"They could ask around, but would get mixed answers and could be deceived through a sybil attack anyway." And not only that, but all that really matters is what block whoever happens to mine the next block thinks is the tip. The "winning" block could be an extreme minority right now, maybe even a third one.

Only once C1 or C2 is found. Before that some nodes will have B1 as tip, while others will have B2 as tip. Also note that most nodes wouldn't even necessarily know about both B1 and B2: most will only know either B1 or B2. As such, those nodes are not even aware that there is no global consensus.
That's a reason why for larger amounts of money you really want to wait multiple confirmations. 6 is a number commonly accepted as safe.

Aren't competing blocks still propagated because they may be needed for a reorganization? Or do they only get requested once it becomes clear they are needed?

Yeah, not sure but I think they are actually (was bit confused by transaction double spends which aren't). But even then there's a (small) period of time where the node doesn't know. I also don't think SPV clients would get to know about the non consensus state.

Node only relay blocks that become part of their best chain. They have no rational interest in helping a competing chain succeed. When there is a reorganization, all blocks in the new side of the fork are relayed at once.


text:
Bitcoin Blockchain in the Quantum computing era
The design and the evolution of quantum computers has been one of the "hot" topics during the last 20 years.
My question is about the possible consequences of the rise of quantum computers (through concrete realizations of quantum computers) on the level of the Bitcoin  blockchain architecture.
Given the fact, that the Bitcoin blockchain is strongly based on digital signatures generated through public-key cryptography schemes based on the hardness of prime factorization and that furthermore, the anonymity (and thus "identity") of the users is based on private keys, it is reasonable to think that quantum computers -which are expected to solve in polynomial time  problems related to the prime factorization and thus to "break" those public cryptoschemes (like RSA) which base their security on the (classically) exponential hardness of prime factorization- will dramatically affect the technologies underlying Bitcoin (and other cryptocurrencies) as well.
A first thought I had, was that the rise of the computational power (relative to the problems described above) could easily be compensated -inside the present blockchain structure- by simply using "longer" private keys (with their "length" suitably chosen so that whatever the total hashing power available, going back from the public to the private will remain practically infeasible -as it is today). At the same time, the difficulty of the mathematical problem to be solved for the mining to occur, will also be rescaled so that the 10-min interval for producing a new block will remain unaltered.  Is it that simple (in principle) or am I oversimplyfying? Are there some other important details one should take into account?
P.S. 1: See also: https://manage.kmail-lists.com/subscriptions/web-view?c=yMWFtj&r=5F9DLpu&m=wYXDhP&k=1dc8ecb6243f9dced47626ac0221f800 for a relevant discussion.
P.S. 2: this question is partially related to What effects would a scalable Quantum Computer have on Bitcoin?

You're not oversimplifying. What you write is simply wrong. Quantum computers don't have a multiplicative value they are better than today's computers. Their advantage is that they can use non-determinism.

Wrong. They are not expected to have "computing power which will be many orders of magnitude greater than the computing power available in today's computers". They are expected to have a different approach to solving a very specific set of computational problems which they are good at solving them. If you remove those incorrect claims from your question, it's possible to answer it. If you want to discuss what quantum computers can and cannot do, we can discuss it in chat, or you can ask on a StackExchange site where this topic is fitting.

Yes.

I have updated the question (especially the statements of the second paragraph). I hope it is more concrete now.

If quantum computers become viable and the approach of factorization of numbers which has been theoretically presented works, this means that Bitcoin will have to use a different way of signing transactions as through the use of quantum computers, it becomes easy (only polynomial time required) to calculate a private key from a public key.
Simply increasing the key length doesn't work. If you double the key length, a classical computer has to work twice as hard to encrypt or decrypt the message but it becomes much, much harder than twice as hard as before to crack the encryption. Signing, in this case, really is just encrypting a hash of a message. However, for a quantum computer, the problem of cracking the encryption, only becomes twice as hard. So you can't keep up with using longer and longer keys because then the increase in effort an attacker has to put in only increases as fast as the increase of effort you have to put into using the keys.
However, there are ways to approach the problem of the signatures currently in use being rendered useless by the advent of quantum computers. Namely, quantum digital signatures.
Because quantum computers aren't faster than classical computers but reduce some exponential problems to polynomial problems, and cryptographic hashes can't be broken using quantum computers, their advent won't impact the difficulty to find a new block.

the link you have provided for quantum digital signatures is helpful and very interesting.

Signing is not just encrypting a hash of a message. This is true for RSA, but not for other digital signature schemes. Encryption is not used anywhere in Bitcoin's design (except locally inside wallet for the password protection of private keys, perhaps).

@PieterWuille Yes, you're right. I was oversimplifying, thanks for noting that. I corrected it.

Signing of transactions in bitcoin is based on addition in elliptic curves, relatively easy to perform, like modular exponentiation (like in RSA), but hard to invert with a classical computer. In both cases, essentially the same quantum algorithm (Shor's algorithm) can be used to invert this operation on a quantum computer in polynomial time with high enough probability to be practical. This is what UTF-8 already wrote.
The proof of work algorithm involves computing a cryptographic hash. This operation is designed in such a way that computing the hash of a string is easy, but finding a string mapping to a given hash is hard. A good hashing algorithm avoids any kind of (exploitable) structure in the definition. Where in the case of RSA and elliptic curve cryptography it is known how the structure of the operation can be exploited by a quantum computer, for SHA256 this is not the case.
For an unstructured search (i.e. one in which you simply have to look case by case) quantum computer still vastly outperform classical computers (using Grover's algorithm) but now the speedup is only quadratic, not exponential. That means that you can find a hash that starts with 2n zeroes in the same number of operations which would allow you to find one starting with n zeroes on a classical computer (with high probability). This would be solved by just adjusting the difficulty.


text:
How can I generate a Dogecoin address from a Litecoin private key?
I'd like to do the following:

I use dumpprivkey to get the private key from Litecoin wallet.
I import this private key into Dogecoin wallet
Which will generate a new Dogecoin address. Both will share the same private key.

The most related post I found is: What happens if you send Bitcoin to a Litecoin address?
However, when I try to directly import, it will give me  the
error:
{"code":-5,"message":"Invalid private key encoding"}
So now, how can I dump the private key and decode into hex and move the prefix from "L" to "D" and regenerate a WIF for dogecoin?
Is there any existing solution for it?

Let's assume we have this compressed Litecoin WIF private key:  T4DRLwPgnkg9jyivjbbnmqJZjHRxeYTy4idAV5uwEuFdyJBGuxXE.
% echo T4DRLwPgnkg9jyivjbbnmqJZjHRxeYTy4idAV5uwEuFdyJBGuxXE | bx base58check-decode

wrapper
{
    checksum 625264444
    payload 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501
    version 176
}

ANSWER for Doge WIF Key:
% bx base58check-encode -v 158 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501

QPn542uVdzBgCfV6nEViShboFTpDd1at8mQpQugEQHgpuLbsgcZe
VALIDATION CHECK:
% echo QPn542uVdzBgCfV6nEViShboFTpDd1at8mQpQugEQHgpuLbsgcZe | bx base58check-decode

wrapper
{
    checksum 2298567751
    payload 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501
    version 158
}

Examine 158, base58check-decode and base58check-encode for more details.

it is awesome, it really help. and also need the  altcoin mapping url is here: https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings#bip44-altcoin-version-mapping-table , However, it is not quite complete, anyone knows how to get the extra WIF version value?


text:
P2SH address decoding
What is the process of decoding the P2SH address?
We have this information so far.
Let's run through an example tx bea1e7ae7ecdc502215717f30d62a12085bb2866d8db730dfb626b60c337534c
The hex script (for the first output) is: 514104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2210250504b2d4245544120506565722d506565722d6e6574776f726b2062657461212102553432353135362e31323234202020202020202020202020202020202020202053ae
script decode gives:
{
    "asm" : "1 04398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2 0250504b2d4245544120506565722d506565722d6e6574776f726b206265746121 02553432353135362e313232342020202020202020202020202020202020202020 3 OP_CHECKMULTISIG",
    "reqSigs" : 1,
    "type" : "multisig",
    "addresses" : [
        "1TestLVFK8DsRYFQkDDwvfsPHqUqWPBe7",
        "1H16KgZg3wHgApvHvZkSocxN6ibzNT9Cc7",
        "1N31mRc4tiGumXdRmb1Bzk9BoG4Bc7Ctbi"
    ],
    "p2sh" : "3KQYMMqMBTv8254UqwmaLzW5NDT879KzK8"
}

Can we break this script down?

I don't believe you can "decode" a script hash. You just have to provide a matching script which when hashed equals the hash provided.

can we derive the p2sh address from the script? I can do it using pybitcointools, but i want to know the steps involved

p2sh address = Base58Check(SHA256(RIPEMD160(script)))

Here is the example
of the transaction from the question
the redeem script is: 514104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2210250504b2d4245544120506565722d506565722d6e6574776f726b2062657461212102553432353135362e31323234202020202020202020202020202020202020202053ae
to derive the P2SH address we do the following:
sha256(redeemScript)
using PHP:
$sha256= hash('sha256',hexStringToByteString($redeemScript));
SHA256: 8b1c6ece53385d6ae3cf3c40fc6239389a7006d9f46047d5d67c3fa78dd2afcc

ripemd160 the resulting hash
$ripemd160=hash('ripemd160',hexStringToByteString($sha256));
RIPEMD160: c25497b8a9bcc393f47abd19a435d1af440916ac

prepend "05" and hash twice
$hashTwice = hash('sha256',hexStringToByteString (hash('sha256',hexStringToByteString ("05" .  $ripemd160))));
double hash: 479ce4efc25c4195ef3cc015d74c45034a2c72f21e322ba30f5c26d872e58b38

first 4 bytes is the chscksum
$checksum=substr($hashTwice,0,8);
checksum: 479ce4ef

compose the address as:

base58-encode: [one-byte version][20-byte hash][4-byte checksum]

$addr= "05" . $ripemd160 . $checksum;
address: 05c25497b8a9bcc393f47abd19a435d1af440916ac479ce4ef

base58 encode
$p2sh=base58_encode($to_encode);
base58: 3KQYMMqMBTv8254UqwmaLzW5NDT879KzK8

and we get the correct P2SH address: 3KQYMMqMBTv8254UqwmaLzW5NDT879KzK8

To compute the 1 of 3 multisig address for the example above, one grabs the 3 public keys from the asm field and simply performs this bx operation:
% bx script-to-address -v 5 "1 [ 04398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2 ] [ 0250504b2d4245544120506565722d506565722d6e6574776f726b206265746121 ] [ 02553432353135362e313232342020202020202020202020202020202020202020 ] 3 checkmultisig"
3KQYMMqMBTv8254UqwmaLzW5NDT879KzK8
Here is where bitcoin-explorer (bx) wiki page details for script-to-address can be found.
Be sure the public keys are in the same order; otherwise, multisig addresses computed will be different. (May be why current multisig transactions need to be signed in the proper order.) Also, notice the 1st public key is uncompresses (is longer) while the other 2 are compressed (shorter).


text:
Creating publicKey from random programtically in c#
I've been looking around I can't understand or find a complete explanation of how to accomplish this, I've tried multiple way even this link How do you get a Bitcoin Public Key from a Private Key which is a similar question but still does not return the same uncompressed public key I create with NBITCOIN, can anyone help, thanks in advance

Post your code and results.  Currently this question is to open-ended to be answerable.  As an aside, if all you want to do is generate Pubkey/Privkey pairs, you could role your own address generator.  See "How to Create Bitcoin Address" here: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

Oh, one more thing. If you make your own C# address generator, you can verify each step of the creation process by using the example provided in the link I mentioned.  If your implementation (or NBitcoin's implementation in your app) is broken, you can inspect which step the app is failing on, and ask more specific questions from there.

Note that creating private/public keys yourself is riddled with dangers and is not advisable. Random number generator problems are common. Edge cases where public keys do not match the private key. And many other situations that can cause loss of money. It's a good exercise to try to do, but think twice before putting anything in production. You're probably better off using an existing library, for example like libpsecp256k1 that Bitcoin Core uses.

Thank you all for your responses, my problem is really creating the Public Key from the Private key which I'm able to create by converting the random value to Hex inserting "80" in front of it and  doing Sha256 twice to get the checksum and add it to the end of the private key and version then I get the WIF by the Base58Encode. But  can't find any good explanation on how to calculate the public Key, any ideas will be greatly appreciated, Thanks in advance


text:
Bitcoin mining: block structure
please note I have made this question previously (link) and I was indicated to visit here.
I am writing a program using GoLang to mine bitcoins. It's part of my college conclusion project and likely won't be used to mine bitcoins since it's not gonna be efficient enough running on regular PC's (facing a race against those huge chinese mining pools). Though it's not originally intended for real usage, my college expects nothing less than a flawless piece of software to mine real bitcoins (in parallel).
So far, I have implemented quite an extensive code, therefore, you guys may assume I already have means to achieve:

Get pending transactions to fill my block (from https://blockchain.info)
Build the merkle tree over the transactions data retrieved
Calculate a sha256 of a given data input (I also understand the concepts behind such hash functions)

I have organized my questions regarding this subject below:
Question 1) I can't precisely tell how to build a block header which would be appended to the block chain. I know it has fields like the root of our merkle tree (which I already know how to calculate) or a version field, but if I was to produce a block header as an array of bytes, how would I do it ? I'd like to see how to calculate each field we need to build the header and how our byte array (representing the header) would look like.
Any dummy data may be used for this example, my focus stays on understanding the process and the data structure.
Please, note I have already read this: https://bitcoin.org/en/developer-reference#block-headers
I have studied quite a lot regarding how the bitcoin protocol works to achieve the code I currently have, but I feel extremely limited on the information I can find online regarding the internal details of the bitcoin protocol:
Question 2) Is there any online technical information you guys would consider useful for me to read regarding the headers subject and/or anything else in bitcoin? Keep in mid that I still have quite some code to write, therefore, I'm taking all the information I can get : )

As an example of how to build a block header, here's a short Python program that calculates this block header's hash:
#!/usr/bin/env python3
import urllib.request
import json
import binascii
import struct
import hashlib
ux = binascii.unhexlify
hx = lambda bin: binascii.hexlify(bin).decode('ascii')

# Load testing data in json format from blockchain.info
url = "https://blockchain.info/block-index/1114939/000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba?format=json"
block = json.loads(urllib.request.urlopen(url).read().decode('ascii'))
print("Original block hash: " + block["hash"])

version = block["ver"]
# 4 bytes, little endian
version = struct.pack("<I", version)

print("Version: " + hx(version))

prev_block = block["prev_block"]
# Reverse hash to go from display format to internal format
prev_block = ux(prev_block)[::-1]

print("prev_block: " + hx(prev_block))

merkle_root = block["mrkl_root"]
# Reverse hash to go from display format to internal format
merkle_root = ux(merkle_root)[::-1]

print("Merkle root: " + hx(merkle_root))

timestamp = block["time"]
# 4 bytes, little endian
timestamp = struct.pack("<I", timestamp)

print("Timestamp: " + hx(timestamp))

target = block["bits"]
# 4 bytes, little endian
target = struct.pack("<I", target)

print("Encoded target: ", hx(target))

nonce = block["nonce"]
# 4 bytes, little endian
nonce = struct.pack("<I", nonce)

print("Nonce: ", hx(nonce))

combined = version + prev_block + merkle_root + timestamp + target + nonce

print("Block header: " + hx(combined))

sha256 = lambda x: hashlib.sha256(x).digest()
sha256d = lambda x: sha256(sha256(x))
computed_hash = sha256d(combined)

# Reverse hash to go from internal format to display format
computed_hash = computed_hash[::-1]

print("computed_hash: " + hx(computed_hash))

Here's the output.
Original block hash: 000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba
Version: 01000030
prev_block: cd0594ebccfe15b205125165cc3b66986ed5b2a311cd88050000000000000000
Merkle root: 37022f7a3b9a2b199d53fbf1552be32c141892319966c3ef999d348d74cfb582
Timestamp: 7f476357
Encoded target:  a09b0518
Nonce:  ae5ae1c1
Block header: 01000030cd0594ebccfe15b205125165cc3b66986ed5b2a311cd8805000000000000000037022f7a3b9a2b199d53fbf1552be32c141892319966c3ef999d348d74cfb5827f476357a09b0518ae5ae1c1
computed_hash: 000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba

I hereby show my deepest appreciation Mr. ODell. You were extremely helpful and your code works nice and smooth. Due to your example now I'm able to understand how these underlying bytes are organized to build the header.


text:
Value of `vout` in vin exceeds number of vout elements. Why?
This is a slightly modified version of a transaction. (privacy reasons)
Edit: Sorry, but turns out there is another tx besides this tx:
"txid": "485579924ce684df7aa7a9861abb4b858a8d917aa1df94bf3a234368a250516",
            "version": 1,
            "locktime": 0,
            "vin": [
                {
                    "coinbase": "033934050d00456c69676975730054ca7075fabe6d6de7cbb1e6f6ca2ed785b50b0bea44f69887952d5e359f5f7478ff677e2e9064f2400000000000000002f737333382f0050dd79739f7f000094fe0a00",
                    "sequence": 4294967295,
                    "n": 0
                }
            ],
            "vout": [
             .
             .
             .
             73 => [
              EXPECTED VALUE!
             ]

Now I am thoroughly confused :( . Please feel free to link to some relevant reading materials..
{
    "txid": "a831a97917a3ae8a3c0cd700ed7ef0529b8218d3f71ed16152c7898c3d909e",
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "485579924ce684df7aa7a9861abb4b858a8d917aa1df94bfa234368a250516",
            "vout": 73,
            "sequence": 4294967295,
            "n": 0,
            "scriptSig": {
                "hex": "48304502210098fa80b386bfc99d5aed9bd09ff41b0b7a92c92025c44f60ef6319d3e3421a02204a838cff88cfa0bece496d65d21811f873a21fbb36a955bbe30264830a3ee5f0012102c651a011009e2c7e7b3ed2068857ca0a47cba35b73e06c32e3c06ef3aa67621d",
                "asm": "304502210098fa80b386bfc99d5aed9bd09ff41b0b7a92c92025c44f60ef6319d3e3421a02204a838cff88cfa0bece496d65d21811f873a21fbb36a955bbe30264830a3ee5f0[ALL] 02c651a011009e2c7e7b3ed2068857ca0a47cba35b73e06c32e3c06ef3aa67621d"
            },
            "addr": "1GWFxtwWmNVqotUPcKVL2mUKpshuJYo",
            "valueSat": 1552750,
            "value": 0.0155275,
            "doubleSpentTxID": null
        }
    ],
    "vout": [
        {
            "value": "0.01551750",
            "n": 0,
            "scriptPubKey": {
                "hex": "76a9141ed14f2bc369ac010e3c9c29347c60c15ff688ac",
                "asm": "OP_DUP OP_HASH160 18ed14f2bc386ac010e39c29347cec60c15ff6 OP_EQUALVERIFY OP_CHECKSIG",
                "addresses": [
                    "13GoELcets2qtNo3nQdEYdSWfTk9p8K4F"
                ],
                "type": "pubkeyhash"
            },
            "spentTxId": "51f6dc1bd22094f32903a3c7e9d4ffcd7bfa35ca0290eb123e62dcc225127f",
            "spentIndex": 0,
            "spentHeight": 346296
        }
    ],
    "blockhash": "000000000000000002a1c66c63d178919fb8cb029a8012b8d95f6fff6a7d9",
    "blockheight": 341650,
    "confirmations": 84845,
    "time": 1422892529,
    "blocktime": 1422892529,
    "valueOut": 0.0155175,
    "size": 192,
    "valueIn": 0.0155275,
    "fees": 0.00001
}

Questions:
vin['vout'] equals 73 here. Why is this, considering that there is only 1 vout element ?
 I have the impression that the value of vout (in vin) points to the index of the vout (vout['n']). Is that wrong ? If so what does it point to
Also what does vin['n'] points to exactly ?
P.S: I have read In getrawtransaction, what is the vout integer in the vin list? - which explains transactions in great detail.. but I couldn't figureout from there what vin['vout'] integer value is precisely

It points to the output 'n' in the transaction which that input spends from, not the spending one.

ok, since everything is stored as transaction, this makes a whole lot sense. Thanks. Just please clarify whether It here refers to vin['vout'] OR vin ['n'] ?