text:
Why does a malicious miner need more hashing power than the rest of the network combined?
I don’t quite understand why a malicious miner needs more hashing power than the rest of the network combined.
When miners are solving a hash puzzle, aren’t they solving the puzzle individually? If so, a malicious miner merely needs to be the most powerful node in terms of her hashing power. But I guess miners are actually solving the puzzle together? In this case, it makes sense that the malicious miner needs to have more than 51% of the hashing power.
edited: November 21, 2018
My question is not how to pull of the 51% attack, but why a malicious miner needs more hashing power than the rest of the network combined.

"I don’t quite understand why a malicious miner needs more hashing power than the rest of the network combined." To do what? It's not clear what this question is about.

Right. Let me clarify: to pull off the 51% attack and double spend.

I don’t quite understand why a malicious miner needs more hashing power than the rest of the network combined

Generally speaking, a malicious miner is one attempting to perform a double-spend or reverse the block-chain.
A miner can attempt to broadcast any block, but it will get rejected if the receiving nodes do not agree with it (checking against consensus rules).
It is important to remember that Bitcoin nodes will always favor the chain with the most amount of proof-of-work (chainwork); this is specified in the protocol's node implementation. The malicious miner needs sufficient hash power to recalculate more blocks than the current chain such that it will have more proof-of-work. Once the attacker's chain has greater chainwork, nodes will discard the existing chain in favor of the attackers.
The miner is indeed required to have more power than the rest (the "honest" part) of the network combined. The miner would need a majority of the hashing power. You will often hear this referred to as a 51% attack.
Additionally as Learn Cryptography suggests:

Hitting 51% network control is not a guarantee of success, just the point where success is likely. In fact, you could attempt this sort of attack with much less network control, but your odds of success would be very low.

This is also why it is recommended for users to wait until a transaction has over 6 confirmations as it gets exponentially more difficult for an attacker to double-spend as confirmations build on top of the transactions current block. With 51% hash power and 1 confirmation, the attacker is practically guaranteed to be successful in a double-spend.
You can calculate your own attack probabilities for this here

When miners are solving a hash puzzle, aren’t they solving the puzzle individually?

Miners do their hashing independently, yes. Each miner will check many nonces for the current block until either a solution is found that meets or is below the target, or the block has been broadcast by someone else.

You're misstating the question by leaving out the weird "rest": "The miner is not required to have more power than the entirety of the network.".

Actually in the context where the malicious miner does NOT yet have any hashing power he DOES have to acquire more than the WHOLE (and thus the rest of the) network combined (counter to your answer). And in the context of him already having some hashng power he will need to grow until he DOES have more than the rest of the network combined. Both of those statements are consistent with your 51% explanation

@Jannes Whoops, you are correct. I did not think it through. I appreciate the edit.

Let’s say Bob owns the 30% of the hashing power and other ten people own 7% of the hashing power for each. If they are mining independently, probabilistically speaking, doesn’t that mean Bob can almost always win?

My question is not how to pull of the 51% attack, but why a malicious miner needs more hashing power than the rest of the network combined.

The malicious miner creates two transactions that conflict. He mines a chain including one transaction and he broadcasts the other transaction to the world. He waits until the worlds has included the transaction and the transaction has enough confirmations that someone has relied on it. Now, to undo the transaction and successfully double spend, he has to make the chain he's mining longer than the chain everyone else is mining.
Only if he has more mining power than everyone else will the chain only he is mining eventually be longer than the chain everyone else is mining. The longest chain wins, so the double spend only occurs if his mining power exceeds everyone else's.

Even though every miner is individually working on its own block template (puzzle), as soon as another fresh block comes in, the puzzle is quickly changed to incorporate (build on top of) the fresh block and the work continues. From the perspective of the attacker all miners are cooperating as though they were one.
That does mean an attacker can increase his chances by timing his attack when the rest of the network is itself temporarily split (partitioned) on two or more chain tips. This happens naturally every week or so when two competing blocks are found at the same time. But could also result from a consensus bug or problems at one or more large pools (misconfiguration or from for example a DOS attack).

Because the rule is that everyone follows the most cumulative work. Miners solve the puzzle independently but since the blocks are chained they build on top of each other's work. If a malicious miner wants to produce the longest chain by himself over a long period of time he must have the majority of the hash power.


text:
Checksum generation for seed
I am trying to generated the checksum for the mnemonics (BIP39) but can't get the correct value.
I used 3 resources

This explains the mnemonic generation https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic
This contains test vectors
https://github.com/trezor/python-mnemonic/blob/master/vectors.json
This is the word list
https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt

I can't get the first test vector to work out.
I SHA256 0x00000000000000000000000000000000 into 374708fff7719dd5979ec875d56cd2286f6d3cf7ec317a3b25632aab28ec37bb
The first four bits, which are the checksum bits, are 0b1101
That makes the last 11 bits of seed + checksum 0b00000001101, the last word of the mnemonic. Corresponds to 13 or index 12 "accident". However in the test vector it's index 4 "about".
I get the wrong word for every test vector. Probably a silly mistake. Thanks.

The checksum is expressed in Hex, so I believe the first character '3' represents the first four bits of the checksum string? If so, this is 0b0011. Word "about" is actually index '3' because the word list is 0-indexed (hence all zeroes maps to "abandon").

You are using the wrong byte-order. In big-endian the hash is 0b0011011101000111000010001111111111110111011100011001110111010101100101111001111011001000011101011101010101101100110100100010100001101111011011010011110011110111111011000011000101111010001110110010010101100011001010101010101100101000111011000011011110111011 so the first four bits are 0b0011 = 3 = about
You can find a python implementation of the mnemonic validation here

source: Stack Exchange

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

sort: votes


text:
broadcasting error for raw bitcoin transaction testnet
I am trying to create a raw transaction and send it to the testnet. I am using testnet keys and here is the simplified readable output from my script:
decoded private key:  efd0171bc0e1a973c75d97cdf38ecccfb2e70227a23cfcdadfed8d9dd1f198c6dc

testnet private ky =  d0171bc0e1a973c75d97cdf38ecccfb2e70227a23cfcdadfed8d9dd1f198c6dc

Receiver public key:   a4842eed5a2c6fd7b71a238632f268d5831dacc0

out1Script:  76a914a4842eed5a2c6fd7b71a238632f268d5831dacc088ac
out1 script length in bytes =  25

My public key:  2431e05399f655c52f2e7ab6227837c94d450312
out2Script:  76a9142431e05399f655c52f2e7ab6227837c94d45031288ac
out2 script length in bytes =  25

Message to sign:  f1c7146e665f9b59a6cce31526d85abb2d76859ba13219e9f8cf8e0d51051e45

my pub k without 04 part added:  be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881
pub k len:  128 that is 64 byte long

signatureeeee:  30450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c
signature lenght:  142

verify signatureeeee with pub key without '04' added that is derived directly from private key:  True

wif pub ky:  2431e05399f655c52f2e7ab6227837c94d450312
pub ky from pr ky:  be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881

sigscript:  4830450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c014104be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881
sigscript lennn:  278
pubky len in sigscript:  65

Formatting of real transaction:
version------------------- 01000000
transaction used---------- 01
transaction out Hex------ 245d84ae31c473495d2ba9b3a57b44196d634acf8a8d689960550345422a01fd
transaction out index----- 00000000
signing script size------- 8b
sigScript----------------- 4830450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c014104be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881

-----sigscript formatting----

sig size---- 48

signature--- 30450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c

how this script applies----- 01

pub ky len--- 41

pub key-- 04be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881

this pub key is 65 byte long dueto '04' added
---end sigscript formatting----

sequence------------------ ffffffff
no. of out trxn----------- 02
out1 value---------------- 00c4090000000000
out1 script len----------- 19
out1 Script--------------- 76a914a4842eed5a2c6fd7b71a238632f268d5831dacc088ac
out2 value---------------- c0cf6a0000000000
out2 script len----------- 19
out2 script--------------- 76a9142431e05399f655c52f2e7ab6227837c94d45031288ac
lock time----------------- 00000000

Transaction of hex string:
0100000001245d84ae31c473495d2ba9b3a57b44196d634acf8a8d689960550345422a01fd000000008b4830450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c014104be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881ffffffff0200c40900000000001976a914a4842eed5a2c6fd7b71a238632f268d5831dacc088acc0cf6a00000000001976a9142431e05399f655c52f2e7ab6227837c94d45031288ac00000000

I am using transaction in hex string to broadcast using https://live.blockcypher.com/btc-testnet/pushtx/
which shows this error:
Error validating transaction: Error running script for input 0 referencing fd012a424503556099688d8acf4a636d19447ba5b3a92b5d4973c431ae845d24 at 0: Script was NOT verified successfully..

The 0 index in that transaction is:
OP_DUP OP_HASH160 2431e05399f655c52f2e7ab6227837c94d450312 OP_EQUALVERIFY OP_CHECKSIG

tried broadcasting using: https://testnet.blockexplorer.com/tx/send
which shows this error:
16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element). Code:-26

When I decode the transaction using: https://live.blockcypher.com/btc-testnet/decodetx/
it shows:
{
    "addresses": [
        "mipLNRZc9oo2fKFzhfwJVNy1t29VsqHRvS",
        "mvWqTmhjEyMkymTm4VMFWLPQhzGwo6RPGM"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 6499,
    "hash": "28aa9b738ec668c62280c7d7cb19c1b907ec10427050902609a54264774c77ca",
    "inputs": [
        {
            "addresses": [
                "mipLNRZc9oo2fKFzhfwJVNy1t29VsqHRvS"
            ],
            "age": 1489541,
            "output_index": 0,
            "output_value": 7646499,
            "prev_hash": "fd012a424503556099688d8acf4a636d19447ba5b3a92b5d4973c431ae845d24",
            "script": "4830450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c014104be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881",
            "script_type": "pay-to-pubkey-hash",
            "sequence": 4294967295
        }
],
    "outputs": [
        {
            "addresses": [
                "mvWqTmhjEyMkymTm4VMFWLPQhzGwo6RPGM"
            ],
            "script": "76a914a4842eed5a2c6fd7b71a238632f268d5831dacc088ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 640000
        },
        {
            "addresses": [
                "mipLNRZc9oo2fKFzhfwJVNy1t29VsqHRvS"
            ],
            "script": "76a9142431e05399f655c52f2e7ab6227837c94d45031288ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 7000000
        }
    ],
    "preference": "low",
    "received": "2019-05-02T00:31:23.148760954Z",
    "relayed_by": "54.162.99.128",
    "size": 258,
    "total": 7640000,
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 2
}

So far what I have found is there some sort of confusion in sigscript part because the address where coins are sent is :2431e05399f655c52f2e7ab6227837c94d450312 which is '04' added to the pub key and applied sha256 to this new key and then ripemd160, but signature can only be verified with the pubkey without the 04 part.
So now, I am not sure how to proceed further. If anyone needs the code to look I am happy to provide it.

Your signature is OK. So, something is wrong with your digest calculation
static void test_sig ( )
{
  const MyKey32 priv ( QByteArray::fromHex ( "d0171bc0e1a973c75d97cdf38ecccfb2e70227a23cfcdadfed8d9dd1f198c6dc" ) );
  const MyByteArray pub ( priv.getPublicKeyClassic ( ) );
  const MyByteArray sig ( QByteArray::fromHex ( "30450221008eaa588a4037a1cd87115853ad28fc215b0ba2cfa7b1327675563bbd971939e302204d245c9092f0c28f3f31ad1bcccb4aef5c7fe718d2a20c39a94358eb8b61845c" ) );
  const MyKey32 digest ( QByteArray::fromHex ( "f1c7146e665f9b59a6cce31526d85abb2d76859ba13219e9f8cf8e0d51051e45" ) );

  qDebug ( ) << "priv=" << priv.toHex ( ).constData ( );
  qDebug ( ) << "pub=" << pub.toHex ( ).constData ( );
  qDebug ( ) << "verify result=" << ( digest.verify ( pub, sig ) ? "passed" : "failed" );
}

Output:
priv= d0171bc0e1a973c75d97cdf38ecccfb2e70227a23cfcdadfed8d9dd1f198c6dc
pub= 04be13acda02dc89ebd1ab87030750b694563c7dac7ebc53b541178e6d04cda33215d712406ff8b705607312d5fea471e9855dbcb963efb63a54e7efeb36382881
verify result= passed

but how is signature is digest calculation is wrong my signature creating code: signing_ky = ecdsa.SigningKey.from_string(my_orgi_hexed_prk, curve = ecdsa.SECP256k1)
verifying_ky = signing_ky.get_verifying_key() signature = signing_ky.sign_digest(hased_raw_tx, sigencode=ecdsa.util.sigencode_der_canonize)

also the error occurs when i am trying to broadcast the the transaction . really appreciate the help

How did you get the digest (message to sign)? in other words, show me the hex of your  hased_raw_tx

02298b9f5c206560aa45a3f61bc01b546834111dc1402f0374e54bb6ca0eb89a

that one was when i run the script again with modification but this is the one from question above: f1c7146e665f9b59a6cce31526d85abb2d76859ba13219e9f8cf8e0d51051e45

How did you get the digest f1c714...? in other words, show me the hex of your hased_raw_tx

hased_raw_tx = hashlib.sha256(hashlib.sha256(raw_tx).digest()).digest()

OMG! what is raw_tx here?

raw_tx = ( version
+ tx_in_count
+ reversed_prv_tx_id
+ index
+ sigScript_raw_size
+ sigScript_raw
+ sequence
+ tx_out_count
+ tx_out_value
+ tx_out_pubScript_size
+ tx_out_pubScript
+ tx_out2_value
+ tx_out2_scriptLen
+ tx_out2_script
+ lock_time
+ (1).to_bytes(4, byteorder="little", signed=False)  #hash code
)

this is the raw tx raw_tx = 0100000001c24bb420c9f9aa54fc54af79e6081759312a83f72776ae3bf0838576b0233a8b000000001976a914a4842eed5a2c6fd7b71a238632f268d5831dacc088acffffffff025c937400000000001976a9142431e05399f655c52f2e7ab6227837c94d45031288ac5a000000000000001976a914a4842eed5a2c6fd7b71a238632f268d5831dacc088ac0000000001000000

this whole code works if i create only one output but it doesnt work if output 2 is added to the real transaction

your rawtx has digest 7a14a699e884980fc842da703dfd8117d9ec3c4d9b57f2f38f19ed6b32913a1d but not f1c7146e665f9b59a6cce31526d85abb2d76859ba13219e9f8cf8e0d51051e45

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


text:
What if all nodes on the lightning network were watchtowers by default?
What would be the costs for forcing every node on the lightning network to provide watchtower services by default so that the burden is shared by other users maintaining the default and with consideration for relative value across the second-layer and for the rate at which users go offline? Could this work for lightning or other state channel networks? Why, or why not?
So, what if all nodes in state channels are arbiters/watchtowers by default, but the cost of computation to support watchtower service on the network for a node (or node pair/channels) depends on the cost of ‘need’ of that node to have state/in channel transactions backed up, which is relative in value to other nodes in the network and to the rate at which nodes fail in the network. State channel users may choose to not use watchtower services at all, use watch tower services but not support it for others in the network, in which case they pay watchtowers at a premium, or to both support ‘watching’ and establish state channels. Also, if the responsibility of ‘watching’ should have a reasonable level of redundancy over periods of time so as to relieve the burden of computation costs of all watchers... sorry
tl;dr - the first part up to ‘why or why not’^^;

Not sure if I get exactly what you are asking for. But some general remarks and thoughts should hopefully give you all the information you need to answer your question.
A watchtower basically needs  a copy of your channels state history. (a subset of the data will be sufficient but let's assume for simplicity that the watchtower needs an exact copy of the history of channel states)
Now the answer to your question depends.
If every watchtower is supposed to have the full history of every state channel on the network we would have a total storage requirement of O(V*E) with V being the number of nodes on the network and E the number of channels. And a single storage requirement of O(E). Unless the person is a supporter of some Bitcoin forks like bcash, one can easily see that this would never scale as the number grows linear with the amount of payments taking place in the lightning network. This it has a storage requirement in the same order of magnitude as storing all transactions in one public blockchain with really large blocks.
However we could say that it is sufficient for every node to be a watchtower of x other nodes. In this way on average (amortized) every lightning node should have a storage overhead of a factor x with comparison to the storage requirements for their own state channels.

Hey, thanks Rene! Still confused: why for simplicity start with the assumption that the watchtower tower has a history of a channels state history? Why not the assumption that they only require the last update/change to the channel? I understand that it puts a heavier burden on a watchtower to maintain an entire history, so why not simplify to ‘I watchtower hold the most recent state of said channel and here it is! I’ve done my job! And saved you from conspiracy...’ or smth like that :/

Sorry, I guess I don’t know exactly how watchtowers must function to guarantee security, privacy, and trustlessness, but as I’m assuming nodes take the burden to become watchtowers by default, I don’t think starting with the most data heavy suggestion/implementation makes the scenario simpler, feasible, or practical

Would say that ‘However we could say...’, that later bit does touch on the idea of nodes in the network sharing responsibility by default, but not in maintaining a copy of the entire history :)

So, essentially the shared responsibility is to keep records of the most recent update to a state channel or several state channels depending on capacity, and provide evidence on layer one that there is a more recent state than of one who is trying to cheat. Does each watchtower (in current proposals) have to keep the entire record so as to match/catch older states being published to layer one? If so, could there be a way to identify state changes that correlate (come from the same channel interactions) without knowledge of every single state in a channel’s history?

AFAIK, Rene is right that ATM watchtowers would need to store an amount of data that is linear in the history of channel states if they are to be as private as we want them to be. Eltoo would change that to basically just saving the latest state. IMHO that is one reason why we're not seeing watchtowers in action: everybody is waiting for eltoo, which would make an idea like yours practical. The other is that right now (without eltoo), watchtowers seem practically unnecessary because the attack they are supposed to prevent is just too risky.

Ok, gotcha—need to do research^^; Thank you both!!


text:
Altcoin Solo mining Help / Advice
I am kind of stumped. I have been mining for about 6 months and have been trying out various methods in that time. I have used CPU, GPU (a combo of both) and most recently been using some older ASICS.
I have used the ASICS in pools and have got them working without any errors, so I thought I'd try my hand with solo mining. Since my ASICS hardware is NOT very new or powerful, I deduced that starting with some scrypt and sha256 altcoins might be best.
I did quite a bit of reading and got to a point where i was ready to start mining (wallets downloaded, configs created and start configs pointed to the correct wallet RPC and port etc.) However, once my miner starts running, (in this case my Butterfly-Labs Bitforce 60GH/s sha256 miner setup for acoin) bfgminer starts up, just like it does when I mine to a pool; finds my hardware, finds my "pool"/host URL shows the block identifier saying it detected a new block and it even shows that it is submitting shares (in verbose mode, informs me "new best share") but it does NOT show that my shares are being accepted like it does when I'm mining in a pool.
(Screenshot)
http://prntscr.com/jm2ob6
Can anyone give me some feedback as to what i might be able to do to fix this?
Thanks in advance!

Shares are an accounting mechanism to allow for miners in a pool to prove how much work they did towards finding the next valid block hash and fairly divide any rewards. With solo-mining, there are no shares to account for, none to be accepted, since it is only you mining. This means if you successfully find a valid hash you will get all of the reward from it.


text:
How to confirm that a bitcoin transaction is confirmed and success?
Coming from ethereum background, I am used to the underlying ethereum tx concept where tx id is not available (returns null) until it is being mined. And after the tx is being mined it have three status which are pending, success and failure, which refers to the transaction state.
Is this the same as bitcoin as I could not see the state of transaction in bitcoin. I can't find any status of the transaction in txid of api returns (i use insight api). How could i ensure that the transaction is in pending/complete state and how can i ensure that the transaction is success or failure. I am thinking of checking 6 confirmations but I don't think that this is a "safe" and proper way as confirmation numbers varies.
To summarize
1) How do i ensure that a transaction is in pending or completed state
2) How do i ensure that a transaction is in success or failure state after completed.
What I did in ethereum to confirm the transaction is completed and success:
1) Keep looping and call the txid api every x seconds to get tx detail until it returns non-null object
2) if it returns an object, i can check the status (which is success or failure) to confirm that the transaction is success.
How it is done in bitcoin way?
Sample output of insights api tx:
{
    "txid": "",
    "version": 2,
    "locktime": 0,
    "vin": [
        ...
    ],
    "vout": [
       ...
    ],
    "blockhash": "0000000000000000000586ebc988140383fd557f9bbc09ca0ac10cff2cb0fafd",
    "blockheight": 525860,
    "confirmations": 9,
    "time": 1528080051,
    "blocktime": 1528080051,
    "valueOut": 3.27637624,
    "size": 290,
    "valueIn": 3.27737624,
    "fees": 0.001
}

Bitcoin transactions do not have a failure state, unlike ethereum. They are either mined, or they are not.
In general, a transaction should be considered final when:

It is included in a block, let's say with block number n
There are 5 blocks after this (current height >= n+5)

You don't really even need to loop every second. You can use the zmq feature of Bitcoin Core, or one of the numerous websocket APIs, or just poll for new blocks every 10 minutes. Once you see your tx in a block, you have one confirmation. Then, you simply need to check the next blocks to make sure they build upon the block with your tx.

Thanks for the suggestion. I don't think so i can make use of zmq feature as i am not hosting my own full node. Probably not websocket api as well (correct me if i am wrong). what do you mean by poll for new blocks every 10 minutes and how can i do that?

and also based on your explanation i need to wait around 1 hour before considered the bitcoin transaction is success since each block is 10 minutes and 6 blocks is required. Am i correct?

6 is the most commonly used number, but for small amounts you could get by with 2 or 3 as well (naturally, it is less secure).
Polling is simply calling any API that gives you the latest block information every 10 minutes in a loop.

I see. thanks for the explaination. is there any web socket or zmq that i can use without using own hosted bitcoin node? as i think probably a pub/sub is a better approach then retrying every x minutes

I recall their being a few websocket APIs around, I believe blockchain.info has one.

I don't see that the web socket able to watch a specific transaction id or block id. How do you watch it.

You could just watch for new blocks in general, and check them for your tx id.


text:
How does "headers first" affect BLKxxxx.dat structure?
Assuming a full node running Bitcoincore v0.10 (with txindex=1), how exactly does the new "headers first" functionality affect the structure of the blockchain data? (Specifically, the blkxxxx.dat data, though perhaps I'm unaware of other files which are ancillary to the data structure).
The README.md for the release specifies that there's no v0.9.x back-compatibility for v0.10 blockchain blk data.

Because release 0.10.0 makes use of headers-first synchronization and
  parallel block download (see further), the block files and databases
  are not backwards-compatible with older versions of Bitcoin Core or
  other software:
Blocks will be stored on disk out of order (in the order they are
  received, really), which makes it incompatible with some tools or
  other programs. Reindexing using earlier versions will also not work
  anymore as a result of this.

How then, does the 0.10 version blk data get parsed by the client? And by extension, why does "headers first" change the structure at all, given it seems to logically set up "a template" for the Tx data to sit?

Having tested with the BlockStore of NBitcoin, the format is the same.
The BLK files are just almost raw blocks (it has a small additional header)
Any stored block in this file has the network to which it belongs with its size, followed by the block data. Those blocks are pointed into by the leveldb database by their (fileId, offset).
The order changed though, I myself used the fact that those blocks were ordered in the past to build the header chain from the bitcoin folder. Such code would break now. (Now I'm connecting directly to the peer node instead of relying on the block folder)

To the best of my understanding, it's just that the blocks are stored in a different order. Headers first synchronization makes use of parallel downloads and the blocks are downloaded (and then stored) out of order. It used to be the case in older versions that blocks were downloaded and then stored in order, so that's whey they added the comment to the README.
I believe it doesn't change the structure of how any individual block is stored, just that they are now likely to not be in the proper order.

Yeah, that makes sense. I am trying to get a low-level, concrete answer on this so perhaps someone well versed in reading the Github discussions can chime in

Fair enough, I recognize this answer is a little bit high-level. But I suspect there may not be any real low-level changes. The Blk___.dat files literally have raw blocks in them, so I feel like the most you can do is store them in a different order

I'll report back :) I do appreciate the response mate. I'm just frustrated that so much functionality of the software - including blk, bitcoin-tx, rest functionality etc etc - is all hidden in Github.

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


text:
Which cryptocurrencies can you margin trade with bitcoin?
I am trying to compile all cryptocurrencies (and fiat currencies) that can be margin trade with bitcoin. Here is a list of the pairs that I have found so far. If you know others please add them in your answer.

ADA: Bitmex, Huobi.pro*
BCH : Bitfinex, Bitmex, Huobi.pro*
BTG : Bitfinex
BTN : Huobi.pro*
BTS : Poloniex
CLAM : Poloniex
DASH : Bitfinex, Poloniex, Huobi.pro*
DOGE : Poloniex
EDO : Bitfinex
ELA : Huobi.pro*
ELF : Huobi.pro*
EOS : BitMex, Huobi.pro*
ETC : Bitfinex, Huobi.pro*, Kraken
ETH : Bitfinex,Bitmex, Poloniex, Huobi.pro*, Kraken
ETP : Bitfinex
EUR : Kraken
FCT : Poloniex
HSR : Huobi.pro*
IOAT : Bitfinex
IOST : Huobi.pro*
LTC : Bitfinex, Bitmex, Poloniex, Huobi.pro*
MAID : Poloniex
NAS : Huobi.pro*
NEO : Bitfinex
OMG : Bitfinex, Huobi.pro*
ONT : Huobi.pro*
QTUM : Huobi.pro*
REP : Kraken
SAN : Bitfinex
TRX : Huobi.pro*
USD : Kraken, OKCoin
XLM : Poloniex (called STR on Poloniex)
XMR : Bitfinex, Kraken, Poloniex
XRP : Bitfinex, Bitmex, Poloniex, Huobi.pro*
ZEC : Bitfinex, Huobi.pro*

I'm voting to close this question as off-topic because this question doesn't fit our format.

Could you recommend another place to post it ?

maybe r/bitcoinmarkets or r/cryptocurrency?


text:
Which security threats in P2PKH lead to the use of P2SH?
To steal a P2PKH output you would have to find the private key of the public key that generated the hash used in the tx. This is impossible to do in a feasible timespan, therefore making the tx secure. What incentivized the use of P2SH? I'm particularly asking in the light of this paragraph of the Bitcoin developer guide:

Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. Receivers do care about the conditions imposed on the satoshis by the pubkey script and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and more difficult to secure than P2PKH pubkey hashes.

I have been unable to find an example of a "reedem script", could you give one?

I don't think P2SH was brought about by security threats at all. I think it came about because people wanted an easy way to use multisig.

Acording to Bitcoin's documentation: "Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. " impliying that long-term security in the P2PKH transaction model is compromised.

@randomname453 If it didn't say "security" I'd argue it's referring to data storage in the Blockchain using multisig

I wrote the paragraph quoted, and it was not at all my intention to imply that P2PKH is compromised.  (P2PKH is vulnerable to exactly the same systematic threats as P2SH, so neither is more secure than the other.)  The security I'm referring to is the security provided by the conditions of the pubkey script, which can be made more or less secure by changing the conditions---for example, a user with two separate devices can require both devices sign a transaction using 2-of-2 multisig, something than single sigs can't do.  Stephen's answer below, especially his final paragraph, is what I'd say.

Note: I've updated the text in the Bitcoin.org developer guide to no longer mention anything about security.  I'm sorry for any confusion.  Here's the patch: https://github.com/bitcoin/bitcoin.org/commit/2c1615e75b89cf78df16d9213b3fd6da5f89cc1b

The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.
So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 out of a set of 5 keys to spend my coins. So, the scriptPubKey that I would like everyone to use when they send coins to me is:
OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG

But each pubkey is 33 bytes and so this makes a script that is ~170 bytes, which is a bit much to encode in a QR code. And it is definitely is too much data for a human to process.
But if I use P2SH, the scriptPubKey is just 23 bytes and the sender doesn't have to worry about what exactly the redeem condition I am setting on my coins is. P2SH works like this. I take the script that I want to be my scriptPubKey and I serialize it (I'll use {} to denote serialization):
redeemScript = {OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG}
redeemScript_hash = hash160(sha256(redeemScript))

And then the scriptPubKey that the sender actually uses is:
OP_HASH160 {redeemScript_hash} OP_EQUAL

Which is just 23 bytes in total. The nice thing is that it provides a layer of abstraction. The person who is sending me coins doesn't need to know how I am keeping my coins secure. All they see is a hash of a redeemScript, but they don't know what conditions that redeemScript actually puts on redeeming the coins.
Basically, P2SH itself is not inherently more secure because the redeem script can be anything. But what it does is enable coin-receivers to easily communicate how coin-senders should send them coins, while letting the coin-receivers dictate the conditions of how/when those coins can be spent.

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


text:
How does bitcoin prevent this network splitting attack?
How are malicious nodes prevented from, after getting the nonce of a new block found by someone else, broadcast it to the other nodes claiming it to be its?
Also, how does the bitcoin system solve the situation of an evil miner who has found the nonce of a block and then sends it with 2 different nodes, each one reaching 50% of the network, therefore having a problem of ownership of this work?
Finally, if all nodes have to check a broadcasted nonce to prove it's legit, how does the network defend against attacks in which thousands of ip adresses (e.g. botnet) start sending wrong nonces, causing a cpu DDoS because of all the peers hashing and checking these nonces.
Thanks for the answers.
Note: As the three questions are related I thought that putting them all in a single question was correct, if not told me and I will edit the text to only contain the first question, placing the other two in different questions.

Your questions indicate a misunderstanding of the mining process. Don't have time for a proper answer now, but take a step back and drop some of your assumptions, then read up on mining again. For example the none is specific for the block that was found, that block contains the address of the money that found the block. Nothing can be changed in the block without invalidating it completely.

How are malicious nodes prevented from, after getting the nonce of a
  new block found by someone else, broadcast it to the other nodes
  claiming it to be its?

The nonce is found against a block which contains the coinbase transaction which claims the reward to the address of the person who found that nonce. So you can't claim it to be yours. You're incentivized to broadcast it to as many peers as possible to help it spread more quickly, but that nonce only works for the block which contains that specific coinbase transaction. Changing the coinbase transaction to claim the coins yourself would result in a different hash of the block and therefore you'd need to find a new nonce.

Also, how does the bitcoin system solve the situation of an evil miner
  who has found the nonce of a block and then sends it with 2 different
  nodes, each one reaching 50% of the network, therefore having a
  problem of ownership of this work?

Not sure I understand this question but if there's a node with more than 50% of the hashing power of the entire network combined, we're in for larger problems.

Finally, if all nodes have to check a broadcasted nonce to prove it's
  legit, how does the network defend against attacks in which thousands
  of ip adresses (e.g. botnet) start sending wrong nonces, causing a cpu
  DDoS because of all the peers hashing and checking these nonces.

Again, nonces work with the hash of a block. All you have to do to check the validity of the nonce is see whether the resulting hash is smaller than a specific value. If it is, you've found a valid block! So there's no problem in checking or DDoSing the nonces. In fact that's what mining is: a race for finding a valid nonce for the next block.

The idea is that, as to check a nonce yo have to spend cpu time, it would be possible to spam wrong nonces to waste the cpu time of all the peers in the network, therefore succeeding in a DDoS.

Checking the validity of a header is very quick, and nodes would drop peers that continously send false information. They would not be able to ddos anyone.

The crux of understanding why the DDoS attack won't work is to understand that checking a nonce is cheap, bad blocks won't get relayed, and consistently bad IP addresses will get blocked. So thousands are way, way less than you'd need to cause significant harm.


text:
Why am I unable to post two transactions (the second from the change address of the first) in the same block?
I'm attempting to make a transaction on the testnet with an OP_RETURN and a
change address in it, and then make a second OP_RETURN transaction from first transaction's change address in the same block. The way my code is currently written the second transaction shouldn't rely on the first transaction being processed (it gets coins from a faucet).
Here is a simplified version of my code that maintains the problem (my "write" function is a modified version of this bitcoinjs-lib example):
var assert = require('assert'),
    bitcoin = require('bitcoinjs-lib'),
    blockchain = new (require('cb-helloblock'))('testnet'),
    dynamicKey,
    dynamicChangeKey;

connect = function (callback) {
    dynamicKey = bitcoin.ECKey.makeRandom();
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    write("Connecting to blockchain!", callback);
};

message = function (callback) {
    dynamicKey = dynamicChangeKey;
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    write("Posting to blockchain!", callback);
};

write = function (arbitraryData, callback) {
    var address = dynamicKey.pub.getAddress(bitcoin.networks.testnet).
            toString();

    blockchain.addresses.__faucetWithdraw(address, 2e4, function (err) {

        if (err) return callback(err);

        blockchain.addresses.unspents(address, function (err, unspents) {
            var tx,
                data,
                dataScript,
                unspent,
                txBuilt;

            if (err) return callback(err);

            tx = new bitcoin.TransactionBuilder();
            data = new Buffer(arbitraryData.toString());
            dataScript = bitcoin.scripts.nullDataOutput(data);
            unspent = unspents.pop();

            tx.addInput(unspent.txId, unspent.vout);
            tx.addOutput(dataScript, 1000);
            tx.addOutput(dynamicChangeKey.pub.getAddress(bitcoin.networks.
                    testnet).toString(), 1000);
            tx.sign(0, dynamicKey);
            txBuilt = tx.build();

            blockchain.transactions.propagate(txBuilt.toHex(), function (err) {

                if (err) return callback(err);

                // check that the message was propagated
                blockchain.transactions.get(txBuilt.getId(), function (err,
                        transaction) {
                    var actual,
                        dataScript2,
                        data2;

                    if (err) return callback(err);

                    actual = bitcoin.Transaction.fromHex(transaction.txHex);
                    dataScript2 = actual.outs[0].script;
                    data2 = dataScript2.chunks[1];

                    assert.deepEqual(dataScript, dataScript2);
                    assert.deepEqual(data, data2);

                    callback();
                });
            });
        });
    });
};

log = function (value) {
    console.log(value);
};

connect(message.bind(undefined, log));

When running this code the first transaction processes correctly, but the second one returns this error:
{ [AssertionError: Invalid JSend Response {"status":"fail","message":"Propagation unsuccessful","details":"TX rejected"}]
  name: 'AssertionError',
  actual: false,
  expected: true,
  operator: '==',
  message: 'Invalid JSend Response {"status":"fail","message":"Propagation unsuccessful","details":"TX rejected"}' }

If I change line 15 to read
    dynamicKey = bitcoin.ECKey.makeRandom();

instead of
    dynamicKey = dynamicChangeKey;

both transactions process correctly, so the problem is definitely in my use of the change key as the next transaction key.
Does anybody know where I'm messing up?

I think my issue was that I was accidentally trying to spend the output from my first transaction (which had insufficient funds for both the given fee and the given amount of change) instead of the output I was getting from the faucet, which I meant to spend. I haven't written a good solution to this problem yet, but I got around it in this simplified instance by building both transactions before propagating either.
Here is one of the transactions, and here is the other.
Here is the horrible code that made them:
var assert = require('assert'),
    bitcoin = require('bitcoinjs-lib'),
    blockchain = new (require('cb-helloblock'))('testnet'),
    dynamicKey,
    dynamicChangeKey,
    transactions = [],
    dataPoints = [],
    dataScripts = [];

connect = function (callback) {
    dynamicKey = bitcoin.ECKey.makeRandom();
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    buildTransaction(dynamicKey, dynamicChangeKey,
            "Connecting to blockchain...", callback);
};

message = function (callback) {
    dynamicKey = dynamicChangeKey; //bitcoin.ECKey.makeRandom();
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    buildTransaction(dynamicKey, dynamicChangeKey, "Posted to blockchain.",
            callback);
};

buildTransaction = function (key, changeKey, arbitraryData, callback) {
    var address = key.pub.getAddress(bitcoin.networks.testnet).
            toString();

    blockchain.addresses.__faucetWithdraw(address, 2e4, function (err) {

        if (err) return callback(err);

        blockchain.addresses.unspents(address, function (err, unspents) {
            var tx,
                data,
                dataScript,
                unspent,
                txBuilt;

            if (err) return callback(err);

            tx = new bitcoin.TransactionBuilder();
            data = new Buffer(arbitraryData.toString());
            dataScript = bitcoin.scripts.nullDataOutput(data);
            unspent = unspents.pop();

            tx.addInput(unspent.txId, unspent.vout);
            tx.addOutput(dataScript, 1000);
            tx.addOutput(changeKey.pub.getAddress(bitcoin.networks.
                    testnet).toString(), 1000);
            tx.sign(0, key);
            txBuilt = tx.build();

            dataPoints.push(data);
            dataScripts.push(dataScript);
            transactions.push(txBuilt);

            callback();
        });
    });
};

propogateTransaction = function (data, dataScript, txBuilt, callback) {

    blockchain.transactions.propagate(txBuilt.toHex(), function (err) {

        if (err) return callback(err);

        // check that the message was propagated
        blockchain.transactions.get(txBuilt.getId(), function (err,
               transaction) {
            var actual,
                dataScript2,
                data2;

            if (err) return callback(err);

            actual = bitcoin.Transaction.fromHex(transaction.txHex);
            dataScript2 = actual.outs[0].script;
            data2 = dataScript2.chunks[1];

            assert.deepEqual(dataScript, dataScript2);
            assert.deepEqual(data, data2);

            callback();
        });
    });
};

propogateBothTransactions = function () {
    propogateTransaction(dataPoints[0], dataScripts[0], transactions[0],
            propogateTransaction.bind(undefined, dataPoints[1], dataScripts[1],
            transactions[1], log));
};

log = function (value) {
    console.log(value);
};

connect(message.bind(undefined, propogateBothTransactions));


text:
What requirements does a router need to fulfill to support a network of 50 miners?
I am running a network with fifty miners, and I am experiencing network problems with my current router from ASUS, because its memory fills up and it requires to restart in order to work properly. I want to get a better router to fix that issue.
What should I look out for when deciding what router to buy to support a network with 50 miners?

Hi Toka, I've touched-up your question to move it away from asking for a product recommendation toward asking general advice on deciding the issue yourself. I did so, because product recommendations are off-topic. Hope that you get the information that you need. :)


text:
Do we need in-app billing for bitcoin-like app?
Apps that use bitcoin contains transactions e.g. deal with a real money. Google says that if we deal with a real money, it has to go over their in-app billing service.
I checked other bitcoin apps on the Google Play, but neither of them seem to have in-app billing implemented.
So do I have to implement in-app billing for bitcoin-like app or I can make transaction without it?
I don't want to build and publish the app which will be blocked as violating TOS.

I'm not sure I understand what you're trying to do. Are you trying to charge the user, then send that money along? Are you trying to make a Bitcoin-like app where you pay to unlock features? etc.

Well basically are we allowed to sell&buy bitcoins without using Google inapp billing?

Are you just talking about letting people receive, store and send bitcoins, or actually letting them exchange bitcoins for dollars, euros, etc (or vice versa)? For the former, there are plenty of apps that do this without in-app billing (I don't see how you could even use in-app billing for such an app). For the latter, you probably would not only need to use Google's payment service but would also probably need their explicit permission.


text:
Displayed transactions may not be correct!
When I enter bitcoind getinfo on my remote ubuntu-Server I get this answer:
{
    "version" : 32400,
    ... (some other info)
    "errors" : "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
}

What went wrong?
How can I fix it?

This is what I did before:
I am running a remote server with Ubuntu 12.04 LTS as operating system. The machine is 800 km away from my home, I am connected to it via SSH. So there is no GUI, I only can use shell commands.
Yesterday I installed bitcoind calling this shell-command (while beeing root) after upgrading all other packeges (apt-get update followed by apt-get dist-upgrade):
# apt-get install bitcoind

bitcoind and 8 or 10 other packages was installed.
Then I edited /root/.bitcoin/bitcoin.conf and entered this:

server=1
  daemon=1
  rpcuser=[my username]
  rpcpassword=[very long passphrade]

Then I did start bitcoind by calling
# bitcoind

The answer was

bitcoin server starting

but even after waiting more then 5 minutes I did not get the shell back (I could not enter new commands). So I pressed

ctrl-c

When I entered bitcoind again, I found that is already was running:

Bitcoin: Cannot obtain a lock on data directory /root/.bitcoin.  Bitcoin is probably already running.

It was also running after closing and re-opening the ssh-conection to the server. So I thought everything was ok now. I also generated a bitcoin-address which worked fine.
Now, about 12 or 14 hours later, I reconnected to the ubuntu-server and entered
# bitcoind getinfo

but the answer was

error: couldn't connect to server

also displaying all active processes by calling top showed me, that bitcoind was not running. So I started it again by entering bitcoindin the command line, but again I didn't get the shell back, so again I had to press ctrl-c. But when I entered bitcoind getinfo after that I got the answer that I posted at the beginning of this posting ("errors" : "WARNING: Displayed transactions may not be correct! ...)
So here are my questions:

What went wrong?
How can I fix it?
How can I start bitcoind and get back to shell again?
How can I stop bitcoind? (I just can kill the process, I don't know any other way)

EDIT 1:
(2014-01-08; evening)
About stopping bitcoind: I found out that the command is bitcoind stop. But when I tried this yesterday I got an error (sorry, can't remember the exact error-message. I guess it sayed "unknown command", but I'm not shure)

EDIT 2:
(2014-01-09; morning)
Yesterday I stopped bitcoind and deleted everything in the directory /root/.bitcoin/ except wallet.dat and bitcoin.conf. Then I started bitcoind again. Even after about 8 hours it still worked fine. Sometimes it took up to about 20 seconds to respond to commands like bitcoind getinfo, but bitcoind always did give the expected answer without any error messages.
So I went to bed and this morning I logged in to my server again and I found that bitcoind was not running (the answer to bitcoind getinfo was error: couldn't connect to server).
So I started it with the command bitcoind. The answer was bitcoin server starting, but I did not get back the shell (I am unable to enter new commands). So I opened a second shell and entered bitcoind getinfo there, and after a few seconds the server responded with an status-json-object with an empty error-string (which means: no error). So I think the start was successful. But the first shell (where I did start bitcoind) is still hang up, since more than 30 minutes now.

Short answer: it looks like you have a very old version of the Bitcoin client and need to upgrade. I'll try and post a more compete answer later.

@NateEldredge: No, it is the newest available version for ubuntu. Yesterday I wrote in my question: ”Yesterday I installed bitcoind...“ So the date of installment was 7th of jan 2014. And I did post the version number. It is 32400.

You are running bitcoind 0.3.24.  This is a very old version that won't work properly on today's Bitcoin network. The latest version is 0.8.6.
It appears that the Ubuntu maintainers have not updated the version of bitcoind in the standard 12.04 repository; so you'll have to get a current version from somewhere else.  The Ubuntu developers maintain a repository of their own for bitcoin, so you can install the latest version by doing:
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

You can also get these instructions from an "official" source by going to http://bitcoin.org/en/download and following the "Ubuntu (PPA)" link.
In answer to your other question, when you run bitcoind without arguments, it runs in the foreground and accepts commands on standard input (after a delay of a minute or two while starting).  You can exit it by typing stop.  You can also run it in the background by doing bitcoind -daemon, and then feed it commands by running bitcoind getinfo, etc.

"add-apt-repository ppa:bitcoin/bitcoin" did not work (unknown command add-apt-repository). So I edited sources.list and inserted this line: "deb http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu precise main". After that I called "apt-get update" and got an error-message telling me that a public key could not be found. So I had to call "apt-key adv --recv-keys --keyserver keyserver.ubuntu.com [key-id from error-message]". Then "apt-get update" did work and with "apt-get dist-upgrade" I could upgrade to version "80600" (which I believe to be 0.8.6).

@HubertSchölnast: Ok.  apt-add-repository does this in one step.  You apparently don't have it installed but it's in the python-software-properties package (in 12.04).

@NateEldredge In the comment above this one you wrote "apt-add", but in the answer you wrote "add-apt". I think one of the two might be wrong. ;)


text:
Inconsistent mining profitability calculations
I am gathering some btc details from coinwarz api as follows
Bitcoin difficulty: 711697198174
Bitcoin reward: 12.5
My personal hash rate: 1.425 TH/s
I then try to calculate  amount of seconds it would take me to mine 1 coin, so
(711697198174 / 100) / 1.425 = 499436630297

The reason I am dividing difficulty by 100 above is so I can keep using my hashing power in TH/s
After this I try to calculate how many coins I can mine per day:
86400 / 499436630297 * 12.5 = 0.0002162436502

where 86400 is number of seconds in 24h. I get 0.0002162436502 coins per day, however every calculator I used online returns value similar to 0.00050348 coins per day.
I think this 0.00050348 is correct value, but I don't understand where my calculation is wrong

The problem is that you're not using the correct conversions:

The reason I am dividing difficulty by 100 above is so I can keep using my hashing power in TH/s

There are 1,000 GH to a TH.

difficulty / hashrate[GH/s] = time[s]

difficulty and hashrate stand in the following ratio:
difficulty = hashrate[H/s] / 7158388.055

Note that the formula uses hashes not gigahashes.


text:
How can I keep my disk usage under control when regularly running the Bitcoin Core functional tests?
What directories should I delete regularly to keep my disk usage under control when regularly running Bitcoin Core and the unit/functional tests?

This was answered on Twitter by various individuals.
You should remove the directory /tmp/test_common_Bitcoin Core regularly. For Martin Leitner-Ankerl this was 6GB of leftover files (leftovers only happen when tests fail or are canceled).
theStack also recommends running rm -rf /tmp/bitcoin_func_test_* every now and then.
The /tmp directory is usually only deleted at boot. It is uncommon on modern Linux distros for /tmp to be cleaned up automatically during runtime.
Occasionally (e.g. with the merge of #23371) you need to run rm -rf ./test/cache to force cache regeneration. In the #23371 case the pre-mined chain of the functional test framework changed and the functional tests using MiniWallet would fail (credit: theStack)
For general advice on compiling Bitcoin Core and running the tests see this doc from Jon Atack.

Hello Michael Folkson,
Thanks for sharing insights on controlling disk usage during Bitcoin Core functional tests. To optimize space management, consider:
Mounting /tmp with LVM
Explore using Logical Volume Management (LVM) to mount /tmp, allocating dedicated space. This prevents /tmp from consuming root directory space, enhancing disk usage efficiency.
Implementing LVM provides flexibility and avoids potential issues related to space constraints on the root partition.
Incorporate this best practice for improved Bitcoin Core testing environment performance.
Best regards.


text:
Is there network split risk for Taproot activation with two releases (Bitcoin Core and Bitcoin Taproot)?
In this article from Aaron van Wirdum he states there is a risk of a network split with two releases (Bitcoin Core and Bitcoin Taproot) not following exactly the same activation mechanism(s)? Is this true?
This question was asked by Andrew Asmakov and has been paraphrased.

Every soft fork or consensus change involves a (very small) non-zero risk of a network split. That risk is considerably lower for a soft fork than say a hard fork (where all nodes need to upgrade). That's why soft forks aren't attempted every month or year. All you can do is minimize that risk.
Aaron lays out some scenarios that are theoretically possible. Any incompatibility between "Bitcoin Core" and "Bitcoin Taproot" during the Speedy Trial deployment is in my view highly unlikely. If Speedy Trial fails to activate and we reach November 2022 (please note 2022 not 2021) without miners activating then we are in a similar scenario to the UASF in 2017 where it depends on what the economic majority is running. I can't predict what the economic majority would be running in November 2022 but I highly suspect the delaying of Taproot activation would be at the top of everyone's minds.
Andrew Chow adds in the comments that false signaling in the period after Speedy Trial has failed to activate (Bitcoin Core has no activation mechanism in this period though this could obviously change in the future whilst Bitcoin Taproot is running a BIP 8 deployment) could cause a chain split.

Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hash rate building on the chain enforcing the new rules.

You do have to weigh up these risks of a network split with miners deliberately blocking Taproot activation potentially forever. If we were to say no more UASFs ever again because we don't want to take any network split risk that would be handing miners a permanent veto to block the activations of soft forks that have community consensus. So you have to weigh up the risk of the latter which would be just as concerning (if not more concerning) to people.
So in summary these are subtle trade-offs. A number of developers have worked hard to minimize the risk of a network split. But it doesn't get to zero unless you literally never try a soft fork again. And that would mean that Bitcoin would never seriously improve again.

The UASF is not the only way that a chain split can occur. False signaling can (and has) cause a chain split after activation. Furthermore, a malicious miner could take advantage of these competing activation rules and false signaling in order to induce a chain split which leaves the UASF nodes stuck on an orphan chain. This is in contrast to the typical chain split caused by false signaling which can be resolved by the majority of hashrate building on the chain enforcing the new rules.

Thanks for this Andrew. Will update answer.

No. With a softfork, a network split is only possible if miners create invalid blocks. This is something they can do with or without a softfork, so it is not an issue specific to softforks.
It is important for the economy to use their own full nodes to avoid the risk of being led off by a miner attack in the form of invalid blocks. This remains true with softforks, where upgrading is necessary to retain full node security.


text:
Without using something like Bitcoin Script, how NEM verify the transaction?
From NEM's thread in bitcointalk, it mentions:

NEM doesn’t use so-called “scripts” aka predicates.

I understand how Bitcoin use the script to verify the transaction. May I know where I can read how NEM is going to verify the transaction in detail, without using the script?

You can also check out their github open source repository which they just released

NEM uses some servers as the transaction validators called NIS. User signs the code and then the signed byte is sent over the network which is received and processed by the other servers. If you are not a server then all you need to do is to sign the transaction and send it to the severs and that is why NEM doesn't need a similar script language like bitcoin. However servers should have a complicated mechanism and code to verify transactions.
You can check NEM servers here and anyone with the server software running can be a server.
This creates a server-client architecture which eliminates some processes from the clients.
Resource: Makoto, a NEM core developer


text:
Here is bash script that auto transfers from hot to cold wallet upon threshhold met. Do you see issues?
The idea is to run this via cron job at some interval and have the excess of funds transfered to cold wallet address.
So, I thought it will be easier to open source it so I can give it to the community and have it reviewed at the same time by more eyes.
It hasn't been tested yet. So, any issues you see?
#!/usr/bin/bash
BITCOINCLI="/set/path/to/bitcoin-cli"
MINIMUM_TO_KEEP=0.1
RECEIVERS_ADDRESS=xxxyyyyzzzbitcoinaddress

echo bitcoin-cli executable is: $BITCOINCLI

tempOutput=$(mktemp)
tempOutputErr=$(mktemp)
#echo "$tempOutput"
#echo "$tempOutputErr"
"$BITCOINCLI" getbalance > "$tempOutput" 2> "$tempOutputErr"

#echo "output file:"
#cat "$tempOutput"
#echo "Error file:"
#cat "$tempOutputErr"

outputsize=$(wc -c "$tempOutput" | cut -f 1 -d ' ')
if [ $outputsize -ge 1 ]; then
balance=$(cat ${tempOutput})
else
balance=XYZ
echo "Error: Could not connect to server. Or some other error while tring to find balance. "
rm "$tempOutput" "$tempOutputErr"
exit
fi

echo Balance is "$balance"

sendamount=$(echo "            $balance  $MINIMUM_TO_KEEP  - p" | tr '\n\r' ' ' | dc   )

#echo comp = "$comp"  x
if [ "$sendamount" > 0 ]; then
    echo "Balance is greater than the amount to be kept, which is $MINIMUM_TO_KEEP"
    echo Sending "$sendamount" BTC to the address "$RECEIVERS_ADDRESS"
    "$BITCOINCLI" sendtoaddress $RECEIVERS_ADDRESS $sendamount > "$tempOutput" 2> "$tempOutputErr"
    outputsize=$(wc -c "$tempOutputErr" | cut -f 1 -d ' ')
    if [ $outputsize -ge 1 ]; then
        echo Error while executing sendtoaddress. Could not send the amount. The error is:
        cat "$tempOutputErr"
    fi
else
    echo "Balance is less than $MINIMUM_TO_KEEP"
fi

rm "$tempOutput" "$tempOutputErr"

My thoughts, in no particular order:

Consider if you need a hot wallet at all. If you don't need to send funds, just accept them, you could probably use BIP32 to generate addresses. Downside is that this way is more complicated.
You should probably bail out of your script if bitcoin-cli produces any errors at all. If your Bitcoin node can't figure out its balance, then it won't be able to send a transaction.
It seems like you detect whether bitcoin-cli failed by 1) checking if it produced output, then 2) checking to make sure that it produced no errors. Why not just use its return codes? bitcoin-cli passes on any error codes.
Your script will tell Bitcoin to send to your cold wallet if you have any amount of extra Bitcoin, even a single satoshi. So, if some miscreant sent you an extra satoshi every time your script ran, it would generate a transaction and pay a fee. You should have a higher threshold, like
THRESHOLD=$(echo "$MINIMUM_TO_KEEP 0.01 * p" | dc)

I don't think that Bash can compare non-integers.
if [ "$sendamount" > 0 ]; then

I'm not sure what this will do.
https://stackoverflow.com/questions/11237794/how-to-compare-two-decimal-numbers-in-bash-awk
Include this line before the rest of your script:
"$BITCOINCLI" getblocktemplate || exit

This will cause your script to bail out if your node is still synchronizing.
What's with this whitespace?
sendamount=$(echo "            $balance

Isn't auto replenishment of a hot wallet from a cold wallet defeating the purpose of a cold wallet?

@WizardOfOzzie It's the opposite - hot to cold. And not necessarily. If you have some way of checking that the withdrawals from the hot wallet were caused by legitimate customer activity, automatic hot wallet refill could be secure.

authors: مریم بانو ازادی


text:
Calculating "total received" and balance by an address
This is something which I think should be simple but it's driving me crazy. See for example this list of transactions associated with an address:
https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json
What I want to do is simply arrive at the same total_received, total_sent and balance stats for the given data.
An obvious requirement is to not count the "change" as a new payment to the address. My idea was to simply sum all the outputs in transactions whose inputs are not from the same target address, e.g. if a transaction has an input (or multiple inputs) from A and outputs to B and A, treat this output as change and don't include it in the sum -- only this doesn't produce the same sum as blockchain.info! In this case, it produces 158.11536395 vs 251.24164662. It looks like I'm missing something?
The next step would be to take the list of outputs produced by the first step, and see which are spent and which are not. The sum of the unspent outputs is the current balance. Is this correct?
Anyone?

You are along the right lines, but whether or not it's a change address is irrelevant to how much it has received/sent.

Their API docs show that you need to use the ?limit and ?offset parameters. There was pagination going on, so you weren't actually using all of the transaction data when you calculated 158.11536395 vs 251.24164662 (I got the same numbers with the data at the time of the question).

As the other answer has noted, balances don't technically exist for a specific address. This is because there may be many outputs that are addressed to an address you own, but you can only spend these outputs discretely (I.e. You can say deduct x from my account, you can only say deduct this output amount which was previously awarded to this address).
We can define a pseudo-notion of a balance, though, let's call it the address' unlock-able value (UV), because the owner of the private key for that address can unlock some # of coins by knowing the private key for that address.
Now, to calculate the UV balance, total received, and total sent of an address, you follow this pseudo-algorithm:
Address a;
Uv = 0;
Received = 0;
Sent = 0;
For each (output in blockchain):
    If (output is unlock-able by owner of address a):
        Received += output.amount;
        If (output has been spent):
            Sent += output.amount;
        Else:
            Uv += output.amount;

At the end of all the outputs in the blockchain, the Uv amount will have a value that is similar in concept to a balance. But here we can also see why this is a very tricky notion:

How do you know if an output is unlock-able by owner of address? Sometimes only the key holder themselves can know.
What if an output can be unlocked by, say, 1 of a set of 3 keys? Do you credit the balances of all three keys, or none?

I suspect the way blockchain.info does this is by basically running the above pseudo algorithm (although much more optimized and using a database), but only considering outputs in the Pay-to-Pubkey-Hash format.

Alright, through contacting the blockchain.info support team and some testing I've found that the problem was the API link given in the question is both paginated and rate limited. The following PHP code produces the same values that blockchain.info shows on their site, assuming you don't run into rate limiting problems.
<?php

// Method: POST, PUT, GET etc
// Data: array("param" => "value") ==> index.php?param=value

function CallAPI($method, $url, $data = false)
{
    $curl = curl_init();

    switch ($method)
    {
        case "POST":
            curl_setopt($curl, CURLOPT_POST, 1);

            if ($data)
                curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
            break;
        case "PUT":
            curl_setopt($curl, CURLOPT_PUT, 1);
            break;
        default:
            if ($data)
                $url = sprintf("%s?%s", $url, http_build_query($data));
    }

    // Optional Authentication:
    curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
    // curl_setopt($curl, CURLOPT_USERPWD, "username:password");

    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);

    $result = curl_exec($curl);

    curl_close($curl);

    return $result;
}

$address = "1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ";
$offset=0;
$txs = array();

while (true)
{
    $val = json_decode(CallAPI("GET", "https://blockchain.info/address/$address?format=json&limit=10&offset=$offset"), true);
    if (count($val["txs"]) == 0)
        break;
    else
        $txs = array_merge($txs, $val["txs"]);

    $offset += 10;
}

$uv       = 0;
$received = 0;
$sent     = 0;
$nrefs    = 0;

foreach ($txs as $tx)
{
    $ininputs = false;
    $totalin = 0;
    foreach ($tx["inputs"] as $input)
    {
        if ($input["prev_out"]["addr"] == $address)
        {
            $ininputs = true;
            $nrefs += 1;
            $totalin += $input["prev_out"]["value"];
        }
    }

    $inoutputs = false;
    $totalout = 0;
    foreach ($tx["out"] as $output)
    {
        if ($output["addr"] == $address)
        {
            $inoutputs = true;
            $nrefs += 1;
            $totalout += $output["value"];
        }
    }

    $uv       += ($totalout - $totalin);

    // $received += $totalout;
    // $sent     += $totalin;

    if ($ininputs && $inoutputs && $totalout >= $totalin)
    {
        $received += $totalout - $totalin;
    }
    else if ($ininputs && $inoutputs && $totalout < $totalin)
    {
        $sent += $totalin - $totalout;
    }
    else if ($inoutputs)
    {
        $received += $totalout;
    }
    else if ($ininputs)
    {
        $sent += $totalin;
    }
}
echo "\n";

echo "nrefs    : " . $nrefs . "\n";
echo "uv       : " . $uv . "\n";
echo "received : " . $received . "\n";
echo "sent     : " . $sent . "\n";

I don't think your algorithm is complete. For one, it double counts "change" for payments which goes back to the original address (e.g. address A spends outputs and pays to address B and the change goes back to address A, where it gets counted as it were originally given to it, i.e. it's counted twice: once in the original outputs, and once again as change). This is the gist of my original question: you can't run a simple sum like your own example, so what can you do?

Hmm, so you're saying that you don't want to double-count an address sending coins to itself towards the total received? But what if two addresses send coins back and forth to the other, even if both owned by the same user, is that really any different? You can only go by what's in the blockchain, and if the blockchain says that an address was 'spent from' and awarded coins in the same transaction, then that's what happened.

Trying to infer real world information will only lead you down a rabbit whole where you can be sure you won't cover all the edge cases. Best you can do is go by the blockchain. Now, it might be possible to calculate total unique coins an address has ever owned, adjusting for the mixing that happens in a transaction. While that would be an interesting number to calculate, I don't think it makes the best sense for the 'total received' number. See this for more info on tracking % of coins.

Well, basically, I need to do whatever blockchain.info does, and it looks like one of the things it does is not double-counting change in total received. It looks like it's doing even more, which I'm hoping to find out.

@IvanVoras, see updated answer.

Some of these answers are absurd. Yes, there is a difference between having the key to spend from an address and simply totalling in and out. But if you have the key pair to spend from an address, its final total is precisely exactly a 'spendable balance'.
I have no idea how the block explorers lack a consensus on account balances. I would guess likely the bigger numbers are accurate sums of an address in/out. The inaccurate ones would be lower and are inaccurate probably because they don't compute the coinbase properly for each input that ends up in an address and isn't spent.
Coinbase values are not stored in the chain, they are in the chain parameters, what you might call 'ephemeral consensus'. Coinbase values are calulated according to the block reward halving schedule. Getting a different total at the end can only be because you are not counting all of the valid inputs and outputs, of which coinbase is very very important.

Coinbase values are not stored in the chain, they are in the chain parameters. This is incorrect, the current block reward + fees is very much on chain, in the output of the coinbase transaction. Any block explorer summing up outputs should be able to pick it up without additional work.

Do you mean is that you can infer the coinbase value by the total value of outputs it used as an input?

But you can't say what the next block's coinbase value should be based on the data in the chain. Strictly speaking although a precise number of blocks relates will be found to have a consistent coinbase value, the halving regime, ie, number of blocks, initial subsidy, it is NOT coded, though the result is.
The function GetBlockValue and the start and min subsidy values in the source code dictate the block reward. Like checkpoints... It's what I am calling ephemeral consensus, and any node ignorant of it will fork the chain.

Sure, but you can predict the reward based on the height. Moreover, the current reward is irrelevant when calculating the total sum of inputs and outputs for an address, since all the information you need for that is on the chain. The current block reward has no bearing on that.

The current block reward does matter for generation transactions. However as I learned today the 'value' field tells you anyway and if it's the only tx in a block it's quite clear. But you can only infer from more than halving period number of blocks when it occurs, and it's an edge case, sure, but getting that wrong would lose you a block reward.

The sum of the unspent outputs is the current balance.

Not really, that's just the unspent outputs for a particular pubkeyhash. Balances don't exist in Bitcoin, it's extremely misleading to people to suggest that they do by using this terminology.

What I want to do is simply arrive at the same total_received, total_sent and balance stats for the given data.

It's not a part of the network so it's not even defined what this term could possibly mean. The information displayed isn't consistent between the websites claiming to be able to show a "total received" for an address.

Insight says 521.29736505 BTC
blockchain.info says 251.24164662 BTC
chain.so says 389.85919867 BTC
blockcypher.com says 289.5535 BTC
webbtc.com says 521.29736505 BTC
Chain.com says 251.24164662 BTC
blockchains.io says 1042.59473010 BTC
helloblock.io says 217.80681263 BTC

So who is right?
It's better just not to confuse everyone by showing faulty data to begin with. Extrapolating this information out to people doesn't do any good, and if services are built using these sort of faulty assumptions about the behavior of the network it can be potentially disastrous and lead to loss of funds.

For better or for worse, people in the real world think in terms of account "balance", for their and other people's accounts, so I don't think that is changeable. What do you suggest as an alternative name? "Spendable amount"?
For starts, I'd like to replicate some or any of the non-trivial results (521.29736505 is just a plain sum of outputs, including change). Any ideas on how blockchain.info does it?

Total spendable outputs would be better, but it would be better if this sort of stuff wasn't shown to end users to begin with. I don't think anybody but blockchain.info could tell you how they calculate theirs.

Balances don't exist in Bitcoin, That might be true at a protocol level, but people don't directly construct Bitcoin transactions - they use clients that abstract those details away. I mean, you could apply similar logic to say that Domain Names don't exist, since you're really communicating with an IP address.

A wallet can have a balance, but an address most certainly does not, it has a collection of atomic outputs that can be either spent or unspent. A "balance" implies many things that are just simply not applicable. As for the results above, I don't think anybody actually understands how anybody else is calculating this, which would explain the variance.

@Bitcoin A "balance" implies many things that are just simply not applicable. And saying that you open your web browser to a domain name also implies things that aren't true. And yet, it's a useful abstraction.I don't think anybody actually understands how anybody else is calculating this, True for total_received, but balance is much better defined.

People don't say they browse a web domain, they say they browse a website. The balance abstraction just serves to confuse people ("I spent 0.1 BTC, but there's 0.9 going to this weird address I don't know about did I get stolen from!") and serves absolutely no useful purpose. The "balance" also differs between different websites and implementations.


text:
Comparison of different active cryptocurrencies
I haven't realized until recently how many different crypto-currencies have emerged the last years; coinmarketcap.com lists around 60 of them* and it seems that it isn't even a complete list (for example allahcoin that I've read about recently at HN is not listed).
I guess most of them are derived from Bitcoin and are somehow different trying to solve a real problem, eg Litecoin being more efficiently mined to reduce energy costs, but some are simply clones with only minor twists if any at all, or trying to appeal only specific audiences (gaming community, sex shoppers etc).
I think it would be interesting for me and others, a simple comparison list that explains in a few words how the concept of each currency is different to Bitcoin and what problems are they trying to solve, and not other details such as market capitalization, initial reward, who created it etc.
Related lists:

http://en.wikipedia.org/wiki/List_of_cryptocurrencies (interesting but doesn't explain the differences of the concept)
https://en.bitcoin.it/wiki/List_of_alternative_cryptocurrencies
https://bitcointalk.org/index.php?topic=134179.0 (by far the most complete list and quite close to what I'm asking, but doesn't explain clearly IMHO in all items what are the differences from Bitcoin)

* Follows the list of currencies found in coinmarketcap.com that I'm interested in; description of additional active ones are of course welcome: Litecoin, MasterCoin, Peercoin, Nxt, Namecoin, Quark, ProtoShares, WorldCoin, Megacoin, Primecoin, Feathercoin, Infinitecoin, DogeCoin, Novacoin, Zetacoin, Devcoin, Anoncoin, Digitalcoin, Freicoin, Copperlark, Terracoin, Ixcoin, Cryptogenic Bullion, NetCoin, GoldCoin, Tickets, BBQCoin, StableCoin, Sexcoin, Fastcoin, Deutsche eMark, Unobtanium, MemoryCoin, Datacoin, GrandCoin, Yacoin, FlorinCoin, Mincoin, I0Coin, Tigercoin, BetaCoin, Luckycoin, TagCoin, Diamond, GlobalCoin, BitBar, CasinoCoin, EZCoin, Philosopher Stones, Phoenixcoin, Orbitcoin, Bytecoin, GameCoin, Argentum, Franko, HoboNickels, Noirbits, Joulecoin, CraftCoin, Elacoin, Junkcoin, Spots.

Please formulate the title as an actual question. There's not need for a topic that covers a general comparison between all altcoins, there are plenty of resources for that.

I think it's pretty clear what I'm asking for; if you think you can improve the title, feel free to edit the question. Actually there are not a lot of resources comparing the new altcoins to Bitcoin, if you know some, please share them to the rest of us. I believe this topic is of interest to enough users (it was for me and I had to spend time researching since there aren't good guides covering ALL the altcoins, hence the question).

You probably should start from the source by yourself, look here:
https://github.com/bitcoin/bitcoin/network
2,523 forks of bitcoin. Greatest bump ever.
You should get source of 2 coins that you want to compare, and simply diff it. It is easiest way to understand what's the difference.
# git clone https://github.com/fastcoinproject/fastcoin.git
# git clone https://github.com/asiccoin/asiccoin.git
# diff -Hrin asiccoin fastcoin

92,401 different stings. The more than 70% is a .ts files from /src/qt/locale/. Only names asiccoin and fastcoin are different (:
See,
# rm -fr asiccoin/src/qt/locale
# rm -fr fastcoin/src/qt/locale
# diff -Hrin asiccoin fastcoin

16,955 different strings.
etc.
Look, here you can get algo:
http://www.dustcoin.com/mining
Very good comparison list: http://www.coinwarz.com/cryptocurrency
The third one: http://coinchoose.com/
Also, check this bitcointalk thread:  Cryptsy Survival Guide.
However, nowhere you can get full list. Forks are born every day, not only on github. There are 10-20 forks that I have meet, with hosting on google disk. 20-30 without sources.
Edit1: At the end, read this thread.
Edit2: Look what I've found http://www.poolwarz.com


text:
Are timestamps in transactions trustable?
I need to properly segment transactions by time. Are timestamps in transactions trustable? Can these be forged?
I'm not sure if transaction timestamps are part of the protocol, but I'm particularly interested in the "Received Time" which shows up in blockchain.info . For example, this transaction (api url)
{
   time:1385506952,
   inputs:[
      {
         prev_out:{
            n:2,
            value:50000000,
            addr:"17BPmjqg7mbaWYdff2EjVxra1FBHG4VAN3",
            tx_index:97772745,
            type:0
         }
      }
   ],
   vout_sz:2,
   relayed_by:"127.0.0.1",
   hash:"4054f8170f7fc7c12229a116baead874f22478810b0a7e842aa28403c9b59927",
   vin_sz:1,
   tx_index:99131036,
   ver:1,
   out:[
      {
         n:0,
         value:40000000,
         addr:"1LwmnEn97jcANB68C5BVFQLJJLAm5UTJqW",
         tx_index:99131036,
         type:0
      },
      {
         n:1,
         value:9990000,
         addr:"17BPmjqg7mbaWYdff2EjVxra1FBHG4VAN3",
         tx_index:99131036,
         type:0
      }
   ],
   size:257
}

related: http://bitcoin.stackexchange.com/questions/7404/how-does-bitcoin-figure-out-what-time-it-is

Transactions do not have timestamps, so the timestamp that blockchain.info displays is whatever time their node received the transaction. The time shown will also change to the time that it was included in a block. In general, it is not reliable to trust the timestamp given for an unconfirmed transaction on blockchain.info as it is entirely dependent on their node.

The actual time of a transaction is not that relevant, and neither the precise time a block is minted. In the end, it is about order: in the race to mine the next block, the first valid block is broadcasted to all other miners, and that block is part of the longest chain.
If a miner receives two valid block close to each other, first one from miner B and then one from miner A and the timestamp on block A reveals it was actually mined first, our miner will still include block B because it came in first, and miners are incentivised to start mining the next block as soon as possible.


text:
importprivkey in bitgold-cli not importing the expected address
I'm in the process of trying to import an existing paper wallet BTC private key into a Bitcoin Gold node I setup so that I can grab the BTG that was airdropped there, however whenever I try to importprivkey the public address associated doesn't match what I had generated, and there are no funds there (they are there if I have the right address in the BTG block chain explorer) I tried:

Generating a random new address on bitaddress.org
1MiXQPkKZersaFrPmteiUexGbyLEATxD8x / Ky324ikVv9HAjeoz7CVWQN2zA8bVY3aDU1gJq8tJjpEQRmUgJXCK
Importing that address in the cli - ./bgold-cli importprivkey "Ky324ikVv9HAjeoz7CVWQN2zA8bVY3aDU1gJq8tJjpEQRmUgJXCK" "test" true
Get the address for the private key I just imported bgold-cli getaddressesbyaccount

I'd expect to get 1MiXQPkKZersaFrPmteiUexGbyLEATxD8x but instead get:
bgold-cli getaddressesbyaccount test
[
  "GeZSpX5GYWUAej9ghqJpuRJAX985Ayn99A"
]

What am I doing wrong here?  Why is my public address getting morphed?

Bitcoin Gold uses a different address format than Bitcoin. Even though the private keys can be used across coins, the addresses calculated from them will look different from each other but still encode the same data.


text:
How to create a Safe and secure Bitcoin Paper Wallet?
I am looking to dump my bitcoins in safe place. So can anyone suggest me or tell me the method for creating a secure bitcoin paper wallet.


text:
How to save your bitcoins to avoid gambling
I am a bit addicted to gambling.
Whenever I receive any amount in my blockchain wallet, I play on it and always lost it.
Suggest some ways to save and avoid gambling.

Please highlight how this question is specific to Bitcoin. I tend towards closing this as offtopic, as self-management and behaviour are not in the focus of this site.

Perhaps if you reworded your question along the lines of "How can I receive bitcoin, but be prevented from immediately spending it?" you may get some more generally useful multisig or nLockTime related answers.

Get help. You have a gambling problem. There are a number of resources, I suggest https://www.problemgambling.ca/EN/GettingHelp/Pages/SelfHelpWorkbook.aspx

You could put your BTC in a paper wallet, which makes them less accessible, especially if you store that paper wallet in a bank deposit box or another offsite, secure location. However, this is not really a technical problem. You should seek out a support group for gambling addiction if you cannot control yourself.


text:
What would it take to create my own Bitcoin exchange?
I'm looking into creating a Bitcoin / crypto currency trading platform (say, like Tradeking), as I've noticed there are a few sites out there already, except they all have pretty hefty fees.
So, to reduce fees, is it possible to create my own Bitcoin exchange? What is involved in setting one up? I'm pretty sure I'll need to develop an API, which I can do (I am an experienced software developer). I'll also need a business entity and a business bank account to use for transactions. What else? I see this thread...is there anything else I should consider?
Also, if I do set up an exchange, can I control of the fee rates? Other sites have rates averaging around 0.5%...can I set mine to whatever I want (considering my costs), or am I limited in some way by some third-party entity?

This could be a rather difficult question to fully answer... Have you looked at all on bitcointalk.org?

It would require quite a lot of programming skill and experience in server security as well as scalability.

The programming part by itself shouldn't be that hard. Withstanding DDoS is annoying. The legal issues are the real problem, especially if you offer exchange conventional currencies.

The question definitely provokes the same questions as the one the asker linked, the whole fee part introduces a separate question which at least the present answer doesn't even pick up on. I am confused (especially since you have 3k rep on SO) that you didn't just add a bounty on the exact duplicate question you found and opened another question just concerned with the fee part.

However, I will concede that it is phrased much nicer and thus might inspire nicer answers as well.

@Murch That's pretty much what I was going for. And I wanted to see if there were any other details that other thread had missed.

Setting up and operating an exchange can be quite involved.
A few tiers to start thinking about:  legal, banking, tech+security, and volume.
Legal

The first question is whether you want to operate globally (e.g. Bitfinex or BitStamp) or focus on a national market (e.g. FlowBTC, meXBT).  The next step is to seek legal counsel to help decide where you want to locate and how to incorporate/structure your business.
You want to think about how you can limit your liability and exposure to litigation, as well as what regulatory/compliance requirements are in your jurisdiction, and what they are likely to be in ther near term.
Merkle Tree offers a useful high-level global map of the regulatory landscape.

Banking

What sorts of banking relationships do I need and how can I secure them?
Note that banks can be heistant to provide services to digital currency exchanges.

Tech + Security
You or a partner need to build and maintain complex architecture that pairs orders, executes transactions, and manages deposits and withdrawals.  Major componets are:

Matching engine
Risk management system
Accounting/audit system
Wallet management
Payment gateways

Security is understandably paramount.  Some things to consider:

Sound internal security procedures among your team  - see, e.g.  CryptoCurrency Security Standard (CCSS) (incredibly important, and often overlooked)
Network and hardware security (secure data center, etc.)
KYC (Know Your Customer) + AML (Anti-Money Laundering) solutions
Two-Factor Authentication for users

Volume
Without lots of live volume, all the above is for naught.  It is well worth your time to actively consider all of the below:

Channeling liquidity from large exchanges like Bitfinex to your exchange
Messaging, media presence, brand creation and maintenance, ads and retargeting
User definition (is this a retail exchange, for advanced users?, etc.), and using this to inform UI design and to prioritize features for product differentiation

Hope this is helpful for getting started!
Disclosure - I work at a firm called AlphaPoint (http://alphapoint.com) - we provide white label tech to many of the largest Bitcoin exchanges in the marketplace, including full stack tech and hosting, as well as order routing for day-one liquidity.

You need three components:

A user account system that allows users to register, maintain a balance, deposit and withdraw BTC and other currencies, and place buy and sell orders. You'll need to integrate this with a payment processor to support currency deposits and withdrawals.
A matching engine that looks at the current buy and sell orders and matches orders together and executes the trades.
A Bitcoin wallet to actually store each user's BTC balance. You should use a hot/cold wallet system that keeps most of the BTC offline.

Some challenges:

You need to track each user's Bitcoin balance so you'll need a way to keep the Bitcoin wallet in sync with a database like MySQL or MongoDB. A good way to do this is to combine the blocknotify command with the listsinceblock() JSON-RPC call.
The biggest challenge is keeping your bank account from getting closed. Many banks are wary of Bitcoin and navigating local, state and federal laws can be tricky.

Best of luck!

@Bitlab- Can you give me some more ideas about matchine engine?? Should we design it?? or Is it available in readymade??

You might modify something like this https://developers.google.com/ad-exchange/rtb/open-bidder/

Or this https://openrtb.github.io/OpenRTB/

Bitcoin exchange is not a giant, what all you need is running daemons of the coins in the backend on your server, a front end PHP website which deals with the transactions taking place on the website. You also don't need a bank account, you can accept USD with so many online payment gateways which do not connect with banks.
So what actually happens is you run daemons in the back end they keep sync with the network you use json script to send commands to the daemons and get the response back. When a user comes to your website and he chose to deposit bitcoin he navigates to that page and click on get deposit address this request is sent to daemon and daemon response with a address where he should send bitcoins, once he sent bitcoin you need a cron job to communicate with the daemon to check how many transactions have been confirmed.  Insert confirmed transactions into database and let the user trade with database only. When he place a withdraw request daemon again comes into picture.
In short a exchange is : I came to your casino paid you a $ and u gave me some chips these chips have no value anywhere else but in your casino I kept playing(I can play until I have chips with me) and winning. When I am done with playing and made good amount I came back to you gave you back your chips and took real $
That is how an exchange works

I'm trying to find sort of a business model template, the closest I got to is something really basic but might be helpful to you:
https://bmfiddle.com/f/#/Wn322

Thanks for sharing this, I wasn't aware of bmfiddle - seems like a great way to create and relay business plans.

To create an exchange, you essentially need 4 entities, each one may be composed or one or more sub-entities, but in general the 4 roles do not overlap.

Someone to fund the process for paying salaries of 2, 3 and 4 below. (I am assuming you are this).
Someone to create the front-end (skills depending on how fancy you want it to look).
Someone to create the back-end (the database layer, order matching engine, wallets, deposits, withdrawals, etc). This person/team needs to have detailed knowledge of Bitcoin.
Someone to handle the financial and legal aspects, getting licenses etc. This one needs good connections (apart from the ones of 1.), knowledge of regulations and laws.

Thats for creating it. Once you have it running, you will need people from 2 and 3 to maintain it and another one to additionally handle fiat transactions and to top up the hot-wallets. Needless to say this person must be extremely trusted.

One of the things you need is a good understanding of your countries laws. Many countries have regulations around handling and exchanging money, and without understanding those you could find your exchange shut down, or worse, find yourself in jail on money laundering charges.
The software and algorithms for running an exchange are quite simple, but the regulatory issues aren't, so you'll probably find a lot of the fees exchanges charge go into compliance; i.e. making sure they can continue trading.

You can create an exchange with https://github.com/AdamCox9/nickelbot and it only interacts with other exchanges so there is no need to set-up wallets on the server.

Get more contacts with traders, they will be a part of website popularity.
Setting a price range is determined globally. So keep watching the bitcoin price value for updates.

authors: Эдуард Прохоров


text:
Bitcoin core for Mac OS X stuck at the 95% mark for hours
My Bitcoin Core app (the latest OS X client) is downloading the chain. It has been at the 95% mark for many hours now. It's progressing, but very slowly.
Is this normal?
I would think so, because this is not the first time this happens to me.

Possibly related - http://bitcoin.stackexchange.com/questions/3487/99-done-for-over-1-hour

As long as blocks continue to download, then all is well.
The Bitcoin client is doing a lot of disk i/o and CPU crunching when verifying each block, so hardware performance will matter.  If you have an encrypted filesystem performance issues are exacerbated.
A slight improvement will come when the Bitcoin.org v0.7 client is released.   And large improvements will come with the version after when the LevelDB database is used, improving access speed to reading and writing the data and "Ultraprune" is implmented which lessens the amount of storage.
Other solutions include using Simplified Payment Verification clients.  Electrum might be a choice for you to consider if your hardware is borderline for operating the full Bitcoin.org client node.


text:
GUIMiner stuck at 99% Done for over 1 hour
I have just started up my client GUIMiner for the first time.  It was downloading the block chain without any issue and got up to 99% where it has been stuck for the past 1 to 1.5 hours.
Is this normal behavior?

No, it is not normal.  Which client, and what version?  Can you try shutting it down and restarting the app?

Gotta love it when a port is blocked. I was using GUIMine which ought to add some connection timeout stuff.

@SouthFresh So, is this fixed?

If it is fixed, you should answer your own question. If not, you should post more here so we can try to help.

Network issues were preventing this from completing.

I'll upvote if you add some more details so that it can help future readers.

I'm not sure I remember the blocked port. It's been a while. I"ll check through my settings.

Well, as of now the answer doesn't even say anything about a blocked port. "Network issues" could be anything.