Satoshi's bitcoind implementation bugs I have seen referred in a couple of locations (bitcd and bitcoinj) that fully verifying clients should match the satoshi bitcoind client implementation, including its bugs, presumably to prevent splitting the blockchain.

I guess the bugs that need replicating are in the block acceptance rules, however I failed to find any specific references to the issues in question. The main Bitcoin Protocol Specification doesn't seem to mention any.

Can someone please explain (or link to a document that explains) these bugs?

Edit: The references that triggered my curiosity are the following (my emphasis):

From bitcd :

  It currently properly downloads, validates, and serves the block chain
  using the exact rules (including bugs) for block acceptance as the
  reference implementation (bitcoind).

From bitcoinj:

  To be safe, bitcoinj must match the behavior of Satoshis code exactly,
  including all the bugs. Any deviation at all can be potentially used
  to split the consensus.

I'll try to give a list of the cases I know of. Whether these are considered bugs or implementation oddnesses is debatable, I guess.

The genesis block's coinbase output cannot be spent.
The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY operations pop one element too much from the stack (requiring an extra dummy push in the redeem script).
The checksig operations in a coinbase's scriptSig count towards the sigop limit of a block, even though that script can never be executed.
Encoded public keys and signatures are valid if and only if OpenSSL accepts them, including the many non-standard or simply broken encodings it accepts. Since 0.8, such non-canonical encodings are considered non-standard, but still valid inside blocks.


How do they know which chain is the real one? Basically how are chains kept in sync so that there is only one main chain?

The "real" chain is whichever chain a majority consensus of network participants considers to be real.  There isn't exactly a "real" chain; only an "agreed upon" chain.

Bitcoin is an incentive based system, and in the long term, it is in everyone's best interest to use the chain that everyone else is using.  Bitcoin clients use a "longest chain" rule to determine which fork of the chain is the one they (individually) consider to be "real".  Of course, every block on this chain must abide by the rules which that client deems to be the "real" rules.  When different clients disagree on what these rules are, a hard fork occurs.


Passing incomplete information to an SPV node I am wondering how SPV handles the following scenario:

A transaction has been confirmed by some block X, and funds address y.
At some later block, the transaction's output are spent again
SPV node queries the balances of y, the full node peer returns the answer along with the merkle proof for block X.
But.. the answer doesn't give you the most up to date response, because y funds were depleted in a more recent block...

I know some ideas like UTXO commitments were around but I am not sure that they were ever merged into bitcoin.

So, was this problem ever solved? Or maybe no one tended to it because it was concluded to not be so bad?

This is a a known shortcoming. The SPV protocol does not protect against omission attacks.

An SPV wallet can request a proof that a given tx is present in a given block, and that a given block is part of a given chain. However, it is not possible to prove that the node isn't omitting a transaction the wallet would like to know about without providing the entire block data for each block, at which point you are essentially a full node.

Wallets avoid this by connecting to multiple nodes - as long as there is one honest node in that connection pool, the wallet will receive up to date information.


How to specify ECDSA nonce used in bitcoin signing code? Below is the CECKey::Sign() code (v0.9.3).

bool Sign(const uint256 &hash, std::vector<unsigned char>& vchSig) {
    vchSig.clear();
    ECDSA_SIG *sig = ECDSA_do_sign((unsigned char*)&hash, sizeof(hash), pkey);
    if (sig == NULL)
        return false;
    BN_CTX *ctx = BN_CTX_new();
    BN_CTX_start(ctx);
    const EC_GROUP *group = EC_KEY_get0_group(pkey);
    BIGNUM *order = BN_CTX_get(ctx);
    BIGNUM *halforder = BN_CTX_get(ctx);
    EC_GROUP_get_order(group, order, ctx);
    BN_rshift1(halforder, order);
    if (BN_cmp(sig->s, halforder) > 0) {
        // enforce low S values, by negating the value (modulo the order) if above order/2.
        BN_sub(sig->s, order, sig->s);
    }
    BN_CTX_end(ctx);
    BN_CTX_free(ctx);
    unsigned int nSize = ECDSA_size(pkey);
    vchSig.resize(nSize); // Make sure it is big enough
    unsigned char *pos = &vchSig[0];
    nSize = i2d_ECDSA_SIG(sig, &pos);
    ECDSA_SIG_free(sig);
    vchSig.resize(nSize); // Shrink to fit actual size
    return true;
}

How could I specify which nonce is used in the ECDSA_do_sign()? By nonce, I am referring to the k value described here: http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm.

ECDSA_do_sign() does not allow specifying the nonce. You can use ECDSA_do_sign_ex(), which needs extra arguments for (k*G).x and 1/k instead.

Bitcoin master recently switched to the libsecp256k1 library for signing, which always needs the nonce passed explicitly, and does not require precomputation of the x coordinate and inverse. See the code in Bitcoin Core for signing: https://github.com/bitcoin/bitcoin/blob/0a1d03ca5265293e6419b0ffb68d277da6b1d9a0/src/key.cpp#L75-L92

Disclaimer: I'm the author of libsecp256k1.


Mining bitcoin using LAN and one computer with internet access I have a cluster of 10 computers running linux connected to each other via LAN and one of them has internet connection. Is it possible to set up mining in which the computer with internet acts as the master computer and gets work done from 9 slave computers and mine bitcoin?

It certainly is, you could for example install the stratum mining proxy (assuming that the pool you are mining for supports stratum). You would install the mining proxy on the computer with network access and then configure the miners to use the proxy instead of directly going to the pool itself.

Of course this is just one of many options. Other options include creating a reverse HTTP proxy on the computer with internet access, as the getwork protocol uses HTTP underneath. Also possible would be to tunnel a given port directly to the pool using SSH for example. But I think the mining proxy is the easiest option, and allows for legacy mining software to use the more efficient stratum protocol as an added bonus.


Unconfirmed transaction - Non(e) standard input A few hours ago, I created an offline transaction using the offline transaction tool available at:
https://www.strongcoin.com/downloads/offlineTransaction.zip

I coped and pasted the resulting transaction into the chain at:
http://blockchain.info/pushtx.

The transaction appears to be stuck. It has a high priority but also says "This transaction has a none standard input."

The transaction # is:
5826ae9e76e2edac733bf9633f5b13de3985dc8989d64ba1780e01d7eac76ee2

I did some googling around, but have found no definitive solution. In the meantime, I imported the private key of the sending address into a wallet at blockchain.info (not sure if this can help - it shows that I sent the bitcoins, but the transaction is unconfirmed.).

What should I do? If I wait a few days, will the transaction simple fail & the funds revert back to the sending address? Will sending a second transaction work (possibly after waiting a few day)?

I'm new to the bitcoin thing. I am pretty technical (part of the reason I went for an offline wallet to begin with), and thought I had a firm grasp of what I was doing. As it were, I should have played around more with smaller transactions.

Any suggestions would be very appreciated. Thanks!

Your transaction has obviously hard time getting accepted by miners, thus it is stuck in the unconfirmed transactions pool. If no miner decides to include it in a block (because it's non-standard), you'll wait forever - it won't automatically "fail".

The best thing you can do is create another transaction spending the same outputs, this time with standard inputs though (use BitcoinCore client if unsure). It will be picked up by the miners quickly.


Effect on economy if Bitcoin was widely adopted What would the effects be on the world economy if several million people around the world would utilize the Bitcoin currency for their daily transactions? Would you expect the GDP to grow faster or slower and why?

I am interested in this, because the first thing I want to get straight is whether I would contribute something positive if I supported the project.

GDP would accelerate because of less transactional friction.


What problems exist with the alt coin Namecoin and what can be done to fix them? I like the concept of using a key/value store that is separate from the Bitcoin chain (preventing bloat), but utilizing the Bitcoin hashpower for security.

What are the dominant issues working against Namecoin today?
What can be done to correct those issues?
If you were to reboot the Namecoin project, what changes or improvements would you make?

First, NMC is not worthless, it have a value and is traded on bitparking ( https://exchange.bitparking.com/main )  and btc-e ( https://btc-e.com/exchange ), with decent daily trading volume; people saying nmc is worthless are just people wanting to attract you to other altchains( most of them being scams imo ) .

Second, namecoin is an opensource network, it cant really die as long as people use it.
 Also, namecoin is the oldest and most serious alternative coin ( altchain ) to bitcoin.
 NMC price have gone down with merged mining ( increased supply ), but merged mining also made namecoin very secure and long lasting.
 As long as someone will maintain the software ( https://github.com/namecoin/namecoin ) namecoin will rock as the oldest and best altchain.

Real issues are :

possibility to store small files in the blockchain, could lead to increased blockchain size ( see https://bitcointalk.org/index.php?topic=145278.0 and https://github.com/runn1ng/namecoin-files )
small community, not enough tools, websites, graphical client . . . )


Armory cannot find bitcoin installation in Ubuntu 14.04 I installed Bitcoin Core version v0.11.2.0-g7e27892 (64-bit)
at /usr/bin/bitcoin-qt.

After that I installed armory 0.93.3-beta-e59e10d38c.

When I launch armory it says "cannot find bitcoin installation".
I go to File > Settings and set "Bitcoin install dir" to /usr/bin.

Yet armory keeps repeating that msg.
Is it a bug?

I’m running Ubuntu 14.04 64bit.

you need to copy both "bitcoin-qt" and "bitcoind" files into the installation directory and make them executable (chmod 755 bitcoin*) then try installing in armory.
check this link:
armory FAQ


How the disposable private keys are being shared in Lightning Network? From the Lightning Network paper:

  ... once an updated commitment transaction is agreed upon, the previous commitment transaction pair is revoked by sharing the private keys needed to redeem those encumbered outputs. Thus, A shares its  (throwaway) private key, and B shares its throwaway private key. If A were to sign and broadcast a revoked commitment transaction, B could not only immediately spend its own output, but it has both A's key and its own to generate a transaction which can spend the output which normally go to A after a delay.

It's not clear to me how the throwaway private keys should be shared between the two parties. What if Alice shared her key to Bob but Bob refuse to disclose his? In that case Alice cannot spend the earlier commitment since otherwise Bob can steal her time-locked funds. But Bob could still spend his previous commitment without worrying his fund be revoked by Alice.

Is it considered an unfair situation? And how the protocol address the problem?

So the question is if it would be unfair to Alice if:

Bob wouldn't reveal his secret information and
Bob broadcasts the previous commitment transaction

Now, the only case in which Bob would broadcast the previous transaction is if it would have a higher balance for Bob. That would mean that the intention for the channel state update is that Bob would like to pay Alice for something. However, an update of a channel state (balance) is a two-step process:

Alice and Bob exchange the new Commitment Transactions
Alice and Bob invalidate their prior Commitment Transactions (by sending each other a (secret) piece of information)

That means as long as Bob doesn't reveal his secret information to Alice, the channel state is not considered as updated. Therefore it's perfectly fine for Bob to broadcast his previous Commitment Transaction as it represents the current balance. So it wouldn't be unfair to Alice, as from her point of view she hasn't been paid (yet) anyway. Only after she received the secret info from Bob, she would consider the payment as successful.


How to produce a Hash160 bitcoin address? tl;dr
How should one perform Hash160, using most basic tools?

====================================================

Hi,

I'm trying to figure out, how transactions work in bitcoin.

When I choose inputs for a new tx I want to make sure they belong to a specific address. However, existing txs do not specify previous outputs' addresses, but instead they contain address' hashes.

e.g.:

>> bx fetch-tx 11a1b7ac0a65bd50b7094c720aecd77cfd83d84b1707960fd00dd82a888aab5c --config /home/theo/Desktop/bx-testnet.cfg

{
    hash 11a1b7ac0a65bd50b7094c720aecd77cfd83d84b1707960fd00dd82a888aab5c
    inputs
    {
        input
        {
            address_hash f3b7278583827a049d6be894bf7f516178a0c8e6
            previous_output
            {
                hash 4a3532061d43086299ae9b2409a456bb9638dff32e0858c4ccda27203fb2e4f6
                index 1
            }
            script "[30440220146b8b5b014245a9e27e21122d4dded04c3f39c3a49ac2494743d6f6ae8efff602206d417a4be9c7431ea69699132438510ade1cf8d746607f77d114907762ed1eb301] [023dd2e892290e41bb78efce6ea30a97015ef13eaaa9ebb7b0514485fc365cc391]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address_hash a73706385fffbf18855f2aee2a6168f29dbb597e
            script "dup hash160 [a73706385fffbf18855f2aee2a6168f29dbb597e] equalverify checksig"
            value 130000000
        }
        output
        {
            address_hash ad6e80394af99ece5d7701bf2f457480b93965b7
            script "dup hash160 [ad6e80394af99ece5d7701bf2f457480b93965b7] equalverify checksig"
            value 49525957813
        }
    }
    version 1
}

Say, I want to check which of the outputs can be sent from address mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa
So I take its Hash160 in Python:

>> hashlib.new('ripemd160', hashlib.sha256("mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa".encode('utf-8')).digest()).hexdigest()
'748598cd9b004aecf8a2d97464fb1f2a90562ffe'

That is not the result I expected: a73706385fffbf18855f2aee2a6168f29dbb597e

Meanwhile, this online service calculates hash correctly.

How do I Hash160 a bitcoin address, preferably in Python?

The address is already a hash, together with a 4-byte checksum and a version byte.  To get from an address to a hash160, you don't have to compute sha256 or ripemd160 of anything.  You just have to decode it from base58 back to hex, and discard the unwanted junk.

If you take mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa and base58 decode, you get

 6FA73706385FFFBF18855F2AEE2A6168F29DBB597EF59C240B
 VVxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSSSSSSSS

The first byte (6F) is the version byte; discard it.  The last 4 bytes are the checksum; discard it.  The remaining 20 bytes are the hash160 of the public key corresponding to the address.


Is there any logical way that a "cloud Bitcoin mining" operation could be anything but a scam? A few years ago, I paid (don't remember now if it was in Bitcoin or fiat) for a subscription to this "Cloudhash" scam. Basically, they claimed that I was "renting" a miner in their big facility, or more likely, they used my money (together with many other customers' money) to buy a bunch of miners that they put into a data center or some sort of facility, and then I could "watch the Bitcoins roll in".
As you can imagine, the amount in my control panel never reached above $2, far below what was allowed to be withdrawn. I never made a single dime. As far as I'm concerned, that was a scam. But does it necessarily have to be a scam? Or is there some way that somebody could legitimate run such a thing and actually pay out any kind of meaningful amounts of Bitcoin to the customers?
I read so many stories of people never getting their miners from China, or getting them so late that they had already become obsolete when they arrived. I realized that the power would go out in my apartment even if I did buy one, got it and hooked it up here. Not to mention the noise and heat generated would've driven me insane. It simply was not practical in my situation (which has not changed) to mine myself. That's why that service seemed so attractive to me, requiring me to do nothing but let them mine for me and I would get at least some coins.
I will say that I was skeptical, but I assumed that I would at least get back the money I had put in. Nope. Not even that.
Is there something which mathematically prevents this from ever working out?
Is there such a thing as a non-scam project that does this? Somebody who perhaps has rented a big basement with free power next to their uncle's nuclear power plant or something like that? Wouldn't it make sense for them to use my amount to buy another miner (or part of one) and then I would regularly get "my share worth" of satoshis?
Or am I pipe-dreaming here? Am I a naive fool who fell for the oldest trick in the book? And you all find it funny that I could ever believe that such a thing could exist?

If you found yourself in a situation where you owned a machine which, when running, would create a profit for you, what would you do?

run that machine
set up a business to rent the profits of running that machine to others

The only way the second choice really makes sense, is if you rent it out for more money than you'd expect the machine to make for you on it's own.

Wouldn't it make sense for them to use my amount to buy another miner (or part of one) and then I would regularly get "my share worth" of satoshis?

Mining is very competitive. As a miner you have to minimize your costs to remain profitable, and so I find it hard to believe that any miner which is depending on renting out their hashrate to others will be competitive. There would be a lot of extra work involved in running such an additional operation. Maybe it is possible, but personally I wouldn't bet on it.
If you search around online, you'll find lots of stories of users that have lost money on cloud mining purchases, but are there many that talk about big profits? Not that I've seen at least. That isn't a perfect measure, but it is perhaps telling.


Send and receive money, payment gateway with Golang I'm really newbie with bitcoin development, so I would like to use go for that, so

what I need for?
What libraries can I use for send and receive money, easy and secure?
Are there any examples?
I would like to do it that support user concurrency, How can I do it?

There is a Bitcoin client implemented in Go called btcd which you might want to check out. This should allow you to send and receive money, if you read more about it, I'm sure you'll find plenty of examples.


Why do we need blockchains? We can generate and verify transactions without blockchain - why do we need it? I can generate a transaction, broadcast it to the network, it can be verified multiple times etc.

Let's look at what happens without the blockchain:
You create a transaction and it is relayed through the network. Every node that receives it updates their ledger to reflect your transaction. So far, so easy.

Now, while you're using the network playing fair, there is Mallory, another user, that likes to break things. Instead of just sending his transaction, he sends two conflicting versions of the same transaction (a "doublespend") at the same time to half of his peers each.
These peers do the same as before: They update their ledger and pass the transaction along. However, half the network receives one version, and considers the second invalid and vice versa.

Now, the network is split: Their ledgers are no longer synchronized. Mallory can now send a transaction building on one of the two previous and only half the network will accept it as valid.

This "doublespending problem" is what the blockchain solves for us: The mining process elects a node to author a block containing his version of the past few minutes. As there is only one author elected every ~10 minutes, these blocks can be passed through the network easily before the next is discovered.

As the author can only have accepted one of the two conflicting versions into his recount, all the other nodes know which transaction to accept and which one to drop.

Thus, the blockchain allows us to synchronize the state of the network under adversarial conditions.

I.e.:

Brings everyone on the same page.
No central decision maker.
Every new node can catch up to the current state deterministically without trusting someone not to lie to them.


BTC/USD price changes approximately the same way over many exchanges at the same time, how? I have seen this many times, the same minute the price goes down on GDAX, it also has gone down on Bitfinex and Bitmex and Binance USDT etc. These exchanges have different prices, that's understandable, but how come they follow the same movement and not go all for each own path? I suspect there is something behind all this that brings them together even tho they are different places to trade on. I need to know what this is. Perhaps it's the price of the USD? Is it the same seller(s) selling at the same time over several exchanges?

To be more specific about the "arbitrage strategies" in Tanmay's answer:

Suppose there were a difference in price between two exchanges: at A the price is $10,000 and at B it is $10,100.  Then, in principle, someone could turn a quick and risk-free(*) profit by buying coins on A, transferring them to B, and selling them for the higher price.  This is called arbitrage.  As they do so, it will tend to drive up prices on A: the people who were offering coins for sale at $10,000 on A are having their offers accepted.  Eventually those offers will all be gone, and people who want to buy will have to take the next-best offer, which will be at a higher price.  Similarly, this strategy will also tend to drive down prices on B.

Arbitrage thus tends to make prices on different exchanges converge towards equilibrium.  And it can happen very fast, so significant differences in price, even if they should occur, don't tend to last very long.  Most of the time you see prices that are close together.

I have left out some details: for instance, the arbitrage strategy will incur transaction and trading costs, and it is not completely risk-free since prices could change in between trades.  This is part of why you don't see prices looking exactly the same at all times.  But the principle applies, and it's a fundamental principle in the study of finance.


ecdsa - Create Private key and Bitcoin Address I have the following code:

import binascii
import hashlib
from fastecdsa import keys, curve

# generate a private key for curve P256
priv_key = keys.gen_private_key(curve.secp256k1)
print (priv_key)
print ("______")

# get the public key corresponding to the private key we just generated
pub_key = keys.get_public_key(priv_key, curve.secp256k1)
print (pub_key)

Which returns this:

68553277193328358088381091283586955911631072878513122367770244549235879948867
______
(defdba7ac050b698bc63134bbc495064b5a99125b023d8ae92d21ca43be77961,
 68ed2abc9d36bae64947b94dd15864e3b2f7601b7009c5b9bae8a8775553fea0)

The first one is the private key, and the second one is the public key. How can I convert these numbers to Bitcoin format?

I've tried with this script: https://github.com/bitcoinbook/bitcoinbook/blob/second_edition/code/ec-math.py

But doesn't work in Python 3.5

I solved the problem. This is the code:

import os
import hashlib
from hashlib import sha256

def ripemd160(x):
    d = hashlib.new("ripemd160")
    d.update(x)
    return d

P = 2 ** 256 - 2 ** 32 - 2 ** 9 - 2 ** 8 - 2 ** 7 - 2 ** 6 - 2 ** 4 - 1
G = (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
     0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8)
B58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"

def point_add(p, q):
    xp, yp = p
    xq, yq = q

    if p == q:
        l = pow(2 * yp % P, P - 2, P) * (3 * xp * xp) % P
    else:
        l = pow(xq - xp, P - 2, P) * (yq - yp) % P

    xr = (l ** 2 - xp - xq) % P
    yr = (l * xp - l * xr - yp) % P

    return xr, yr

def point_mul(p, d):
    n = p
    q = None

    for i in range(256):
        if d & (1 << i):
            if q is None:
                q = n
            else:
                q = point_add(q, n)

        n = point_add(n, n)

    return q

def point_bytes(p):
    x, y = p

    return b"\x04" + x.to_bytes(32, "big") + y.to_bytes(32, "big")

def b58_encode(d):
    out = ""
    p = 0
    x = 0

    while d[0] == 0:
        out += "1"
        d = d[1:]

    for i, v in enumerate(d[::-1]):
        x += v * (256 ** i)

    while x > 58 ** (p + 1):
        p += 1

    while p >= 0:
        a, x = divmod(x, 58 ** p)
        out += B58[a]
        p -= 1

    return out

def make_address(privkey):
    q = point_mul(G, int.from_bytes(privkey, "big"))
    hash160 = ripemd160(sha256(point_bytes(q)).digest()).digest()
    addr = b"\x00" + hash160
    checksum = sha256(sha256(addr).digest()).digest()[:4]
    addr += checksum

    wif = b"\x80" + privkey
    checksum = sha256(sha256(wif).digest()).digest()[:4]
    wif += checksum

    addr = b58_encode(addr)
    wif = b58_encode(wif)

    return addr, wif

print("=========================")

from ecdsa import SigningKey, SECP256k1

sk = SigningKey.generate(curve=SECP256k1)
vk = sk.get_verifying_key()
addr, wif = make_address(sk.to_string())
print("Address: " + addr)
print("Privkey: " + wif)


Underclock GPU Memory below "Recommended" Limits on Linux I'd like to try underclocking my GPU Memory. Based on what I've read, this is frequently done to reduce heat without sacrificing hashrate, and can sometimes even boost the hashrate if done carefully.

I seems that those running on Windows have a tool called "Afterburner" that allows them to over/underclock beyond the manufacturer's recommended limits, without flashing their BIOS.

However, under Linux, aticonfig --odsc=XXX,YYY won't allow setting the memory clock any lower than the range displayed by aticonfig --odgc.  Other tools I've investigated, such as AMDOverdriveCtrl, appear to just be front-ends for aticonfig, and therefore limited to what it can do.

I've seen some mentions that flashing on a new third party BIOS rectifies this, but that makes me more than a little nervous, so I would prefer to avoid that.

Would someone please explain, either...

A) How to underclock the memory on ATI GPUs (6850 and 6950, specifically) on Linux beyond the manufacturer's recommended limits, without flashing the BIOS.

... or ...

B) How it's possible for tools running on Windows to have more control over the hardware than those running on linux. (This feels like a slap in the face to me.)

aticonfig respects the settings set in your video card's firmware by your card's manufacturer (frequently, although incorrectly, called a BIOS). However, AMDOverdriveCtrl can clock memory down much farther, depending on the card.

Radeon 5xxx, 67xx, and 68xx series cards should be clocked down to 1/3rd of the core speed (ie, 750mhz should have a memory speed of 250), 69xx cannot clock down far enough to be worth it, and GCN (79xx, 78xx, 77xx) seem to have a limit of 150 mhz less than core (however, although it is not worth underclocking on 69xx, it is worth underclocking on GCN due to automatic memory voltage control done by the hardware/driver; on my 7950 @ 1125mhz, going from 1375 down to 975 dropped my GPU temps 3-4 degrees celsius).

5xxx and 6xxx series cards also have a problem where they will instantly lock up if memory speed is set between around 400mhz to around 600mhz (depending on core speed), so your mileage may vary as always.


how does bitcoind functions in bitcoin exchange model? i mean exchange allows every users a unique BTC deposit address

different users sends btc to different addresses but BTC endsup in same wallet

can i create multiple receiving address by bitcoind (getnewaddress)  or i will have to use HD wallet for that for our users (we are building lotto system on bitcoin)

A wallet is not the same as an address. A wallet is a collection of addresses. Wallets usually also contain the private keys for the addresses and any relevant transactions.

You can get as many addresses from bitcoind as you want with getnewaddress and they will all be part of the same wallet. Any coins sent to those addresses will be part of your wallet.

Also, Bitcoin Core is an HD wallet, but there is no need for you to have an HD wallet to do what you want. HD wallets are only relevant for backups.


Why can bitcoins never be refunded unless the receiver agrees to send back the money? I have used a number of ecurrencies and they all seem to share what I've never understood about BTC, which is that once it is sent, it's gone. Often BTC are sent but legally should be refunded, but because of how BTC work, the sender loses their money.

Why is this?

Bitcoin is like cash: You don't use an intermediary. If you send money to someone, they got it. The only way you can get is back is to make them hand it to you. If there is no intermediary, you can't complain to that intermediary to take money from the person you sent money to and give it to you.

The reason Bitcoin is like cash is that it's designed that way. It's supposed to behave like cash. And the reason for that is (in part) to avoid intermediaries. Using intermediaries means to be exposed to their arbitrariness. Refunds enforced by an intermediary are precisely that: Arbitrariness.

Even if you don't see how arbitrariness is bad: Arbitrariness is very close to despotism and despotism is obviously bad. You, as someone who wants the money they sent to someone else back, rely on an intermediary and have to hope that they decide in your favor. The entity you sent the money to relies on the intermediary to decide in their favor. At least one of you is going to lose. And even if the intermediary tells you to give the money to you, they might decide to give it to the other entity, later on. Or they might freeze the funds and freeze some more funds from one or both entities in conflict to be gain more power.

Can you see how that intermediary became a judge? The only way to avoid this is to carry orders out without the option to undo them except if both the payer and the payee agree. You don't need a special rule for the latter case because the payee can just send the money back in a different transaction.

Furthermore, as Pieter Wuille noted in the comments, refunding is done through payment processors. You are forced to use a payment processor when paying in a fiat currency online but are not forced to when paying in Bitcoin. However, using a payment processor when paying in Bitcoin is still possible. A payment processor can allow refunds even when the good or service was payed for in Bitcoin. The currency doesn't influence this, the payment method does. It's just that you're not forced to use one when paying in Bitcoin.


blockstream API response How do I determine if the current transaction is an outgoing or an incoming transaction from looking at the following API response?

https://blockstream.info/api/address/1A6HUTtraLwTg48AwpQxPwLmTnDGSSJteG/txs

If an address appears in the vout list, it is incoming for that address.

If the address is in the vin list, it is an outgoing transaction for that address.

Addresses may appear in both the vin and the vout.


Is it possible for two nodes to view blockchains differently? Is there a chance, that at some point in time, two blocks will have different number of confirmations, according to different nodes? Like, with difference up to 3-4 confirmations?

The problem I'm having that I have Iquidus Explorer set up as my SolarCoin blockchain viewer and I have 6 as min. number of confirmations until it gets picked up and written in a database, but sometimes, transactions are written there before they show 6 or more confirms here.

Thanks in advance!

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


Is Lightning Network vulnerable to sybil attacks? A dialogue partner of mine claimed that Lightning Network is vulnerable to sybil attacks. He stated that LN needed explicit identities in order to support the "routing" which would cause ending up with whitelists.

Is Lightning Network vulnerable to sybil attacks?

Not true.

You have funds locked into a multisig wallet with party A, B and C. There's nothing to Sybil there: the funds have been transferred and only you and them have keys.

Then you want to transfer money to G. None of your parties has a direct link to G, but C has links to D, E and F. And G is advertised as having a link to D. So C relays your money to D and D relays it to G.

How do you know it's actually G and not some fake G? Because you have out-of-band communication with G, because G is the restaurant you are standing in right now or G is the webshop you are trying to pay. A secret token is exchanged directly between you and the real G, which makes sure we're talking to the correct wallets and any relay transactions can only be redeemed with the knowledge of the secret token.

The example above is simplified of course. In practice the goal is to have more hops between you and G, both because finding a shorter route might be hard/impossible, but also for privacy reasons (it uses Tor like routing and encryption to hide identities and IP addresses).


Is SegWit a step in the direction toward implementing pegged sidechains into Bitcoin? Is Segregated Witness a step in the direction toward implementing pegged sidechains into Bitcoin?

No.

Federated pegging solutions already exists, and some are being deployed in production. This approach relies on having a number of trusted parties that hold the pegged coins on the main chain side until they get pegged out from the sidechain again.

If you're talking about SPV merged-mined two-way pegged, SegWit does not matter. In this approach, the trusted federation is replaced with a hashrate majority signing off on transfers back. It requires support in the main chain for counting miner votes or support, and several proposals have been made. They are not part of SegWit, though.

The downside of the latter approach is that a hashrate majority on the main chain is always capable of stealing the sidechain's coins, as they could simply sign off on an unauthorized transfer. Technology exists (SNARKs) that could one day allow us to build a sidechain where the main chain can fully validate the sidechain's action, but right now, it is computationally infeasible to do so.


Multibit seed/ or files to Electrum wallet i tried moving multibit wallet as explained here but failed.  https://youtu.be/E-KcY6KUVnY i have the seed and password from Multibit wallet and some files from backup folder in the 'mbh......aes' format. Any help i'll appreciate
 Am using linux

You haven't specified how it failed so we can only guess. Here's a more detailed guide. Pay attention to the last two paragraphs and try again.


Proof-of-Stake: What if a bad enactor is chosen by random? My understanding of proof-of-stake is the following:
The node that mines the next block is chosen, randomly in proportion to the amount of nodes they have in the network (ex. person who who owns 5% of all the tokens in the ecosystem has a 5% chance of being selected to mine the next block)

The block gets broadcasted throughout the network.

However, based on this principle of randomness, what if a bad enactor is chosen by chance.

What if a person wants to submit a block w/ fraudulent transactions (ex. instead of Bob sending Alice 1 cryptotoken, the fraudster changes up the transaction to make Bob send Alice 100 cryptotokens - assuming Bob owns 100+ cryptotokens)?

Thanks!

What if a person wants to submit a block w/ fraudulent transactions (ex. instead of Bob sending Alice 1 cryptotoken, the fraudster changes up the transaction to make Bob send Alice 100 cryptotokens - assuming Bob owns 100+ cryptotokens)?

In PoS, block validators lock certain amount of the network tokens into a deposit using a smart contract that designates them as validators. You cannot simply change the output as the signature used to verify 2 cryptokens being sent will not be valid if that number is changed to 100. Thus this transaction would be invalid according to the protocol. If the network determines that the validator has misbehaved then the entire deposit (or in some cases portion of the deposit depending on protocols on different chains) gets slashed. To go into exact technical details as to how it happens you can see Ethereum PoS FAQs here.


bitcoin-cli JSON-serialized error output Is there a way to make bitcoin-cli output JSON-serialized errors? For example if I do

bitcoin-cli getblock foo

the output is

error code: -5
error message:
Block not found

I want the output to be something more like:

{
  "error": {
    "code": -5,
    "message": "Block not found"
  }
}

Behind the scenes, that's what the RPC response body looks like, and I want to tell bitcoin-cli, "Don't pretty-print the error if there is one. Just give me the JSON response."

bitcoin-cli does not currently support dumping the raw JSON-RPC response. The relevant section of the Bitcoin Core code is here https://github.com/bitcoin/bitcoin/blob/2753285be72dd051cf2987ca5c80d0b149914020/src/bitcoin-cli.cpp#L455 .


Why not send BTC between web wallets? In this question, Is it possible to transfer BitCoins from BlockChain to CoinBase?, the answer implies that this is a bad idea.

But for me, this raises a question.

I like to Coinbase's tools for buying BTC straight through my bank account. But I like Blockchain's tools for backing up my wallet in standard encrypted format or cold storage. I would like to be able to exchange BTC on Coinbase, and then migrate those to my wallet on Blockchain.

It seems to me that whether I happen to own both accounts is irrelevant. It seems exactly the same as any other BTC transaction. Is there actually a reason against this?

Is it possible to transfer BitCoins from BlockChain to CoinBase?

Actually, the answer on the linked question states that it is possible, but that one should be careful not to return money back to the sending address, because said sending address might not be associated with the personal wallet, but rather owned by the service itself.


How to accept trade in cryptsy? I am beginner in crypto-currencies, i just created my account in cryptsy and can make buy/sell orders but how do i accept orders from others(i.e open orders(all buy/sell orders)) i can view the list of all buy/sell orders but don't know how to accept those orders?

You cannot accept or reject an order. When you place a sell order (for clarity's sake assume 1 BTC for 100 dollar) and there is no-one with a buy order above $100/BTC you end up in the list of buy orders. When someone thinks "hmm, that is a nice price to pay for a bitcoin" he can create a buy order for 1 BTC (or less) for $100/BTC. Cryptsy looks then if there is a sell order for that price (or lower) and his order will be filled, and you get your money. So if you leave an order open while you go away, it can be filled without you noticing it.

If you want more clarity about the filling of orders, you can look at my answer here.

edit: so if you want to close the deal immediately, buy (or sell) at a rate that there is a seller who sells at that rate. Otherwise the market can go up, and your bid will be missed out.


When I use importmulti with an xprv it never imports the private keys. What am I doing wrong? When I call:

bitcoin-cli getdescriptorinfo "pkh(tprv8iDvhA6eaMDbRuH3D2DTNuH6N6LvMTVrcv7z6sVxyyYvThSaCSa3i3qFVqUgVL4NbVkACxjx3KPWLoP5jvDU3i16hjTnzEFnZuqsnTJ5F4n/*)"

it returns:

{
  "descriptor": "pkh(tpubDEuxqa8tiiuGKNJq6ft3nJwCw7rrWngmCDimPPYGQFMKJBhLpqPdtYT7fzuDbk1AppxRdYjzeUrLaVNQRP7EYghzLDBMguY2LHHHeHMtzhm/*)#0wkkha79",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": true
}

I then call:

bitcoin-cli importmulti '[{ "desc": "pkh(tpubDEuxqa8tiiuGKNJq6ft3nJwCw7rrWngmCDimPPYGQFMKJBhLpqPdtYT7fzuDbk1AppxRdYjzeUrLaVNQRP7EYghzLDBMguY2LHHHeHMtzhm/*)#0wkkha79", "timestamp": "now", "range": 100, "watchonly": false, "label": "Hot Storage", "keypool": false, "rescan": false }]'

It returns:

{
    "success": true,
    "warnings": [
      "Some private keys are missing, outputs will be considered watchonly. If this is intentional, specify the watchonly flag."
    ]
  }

I am importing an xprv because I want to import the private keys, but they always get imported as watch-only.

Why is this? Is it intentional?

You aren't doing anything wrong. This behavior is expected for Bitcoin Core 0.18. The Pull Request allowing private keys to be derived from descriptors and imported with importmulti was merged recently. This functionality will be included in Bitcoin Core 0.19.


What is QuoteAssetVolume and BaseAssetVolume? This is a JSON result for a candle returned by an exchange API for ETHBTC:

{ openTime: 1517340600000,
  open: '0.10635000',
  high: '0.10742000',
  low: '0.10635000',
  close: '0.10687200',
  volume: '600.53200000',
  closeTime: 1517340899999,
  quoteAssetVolume: '27.65975320',
  trades: 1233,
  baseAssetVolume: '259.09000000' }

What is quoteAssetVolume and baseAssetVolume?

baseAssetVolume is the quantity shown as the amount of coins received by the buyer whereas the quoteAssetVolume is the amount paid by the payer


What is the maximum amount I can send with "sendmany()" If I use the sendmany(); function is there a maximum of the output amount?
Example:

The maximum would be 0.01 BTC

data={'address1':amount1,'address2':amount2};

amount1+amount2 = 0.02 BTC

-> But then it would be above the maximum.

Thanks.

The maximum output amount is the full wallet balance minus any transaction fees, many inputs up to and including all that have a positive balance can be combined to create the utxo set used in the transaction.


Tool for calculating profitable coin trading I want to know that if I buy 200$ worth of BTC that when I trade to other coin I'm not trading for less than 200$ worth of that coin. This way making sure I'm never loosing money.

I'm doing this manually right now but it takes forever and is not productive. Is there a tool out there to do this faster? Where I could input the amount of BTC I have and how many of the other trading coins I would get and their value in $?

I'm sure there's a term for what I'm looking for but I don't know it. Hopefully you'll get my example :)

I found a website that can convert any cryptocurrency into USD or other type of cryptocurrency

https://coinmarketcap.com/calculator/

Use this (mostly what your looking for):
https://www.currexy.com/cryptocurrency/converter

Hope this new link above found what you need, if not tell me


Is there a way to get the memory pool in order of newest first? I'm trying to list out the results of getrawmempool by newest transactions first.

Here's what I've got:

getrawmempool returns the memory pool in order of transaction hash, so I'm using PHP to sort it:

<?php
// Get an array of the memory pool transactions
$getrawmempool = $bitcoin->getrawmempool(true); // true = verbose

// Create a new array of "txid" => "time" (just so I can sort it)
foreach (array_keys($getrawmempool) as $txid) {
     $mempool[$tx] = $getrawmempool[$txid]['time'];
}

// Sort the new array
arsort($mempool);

// Print results
print_r($mempool);
?>

Now, this isn't terribly slow, but sorting 10,000+ array values isn't terribly snappy.

Questions:

Is there a way of getting the mempool in order of newest first from bitcoin-cli?
If not, is there a faster/better way of sorting the returned results?

I'd like to play around with all the mempool transactions using PHP. So if I can get the mempool transactions in order along with all the verbose information about each one, that would be handy.

I think you have two options:

1) Patch bitcoin-core and make getrawmempoolentry return the mempool transaction sorted after entry_date. There is boost multi index that would be capable to fast sort the mempool transaction (https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L303)

2) You can try to improve your PHP sort speed. IMHO Arsort is not the best choice.


Does selfish mining actually give an advantage in the absence of transaction fees, difficulty changes, and economic effects? I am reading the Cornell selfish mining paper. In it, their main argument is that a selfish miner can increase the ratio of the blocks he mines relative to the honest miners. I do not dispute this. However, to my understanding, merely denying others their blocks does not help you; just because everyone else is getting fewer blocks doesn't mean you're getting more. (That is, everyone mining normally would be expected to get a certain rate, but if you suppress some of those blocks, then the total rate goes down. So denying others their blocks is not zero-sum; just because everyone else's rate goes down does not imply that your rate goes up.)

Here's a simpler explanation of my confusion. Consider this thought experiment. Let's say 2/3 of the miners suddenly quit mining, leaving it all to a miner who has 1/3 of the hashrate. We can all agree that this miner is at least as well off as a miner conducting a selfish miner attack. (The reason for this is very simple: he could just replicate the exact same strategy used by the selfish miner, except that the honest miners now have no chance of finding a block in this thought experiment.) Nonetheless, they can only mine at a rate of 1 block per 30 minutes, at least until the next difficulty readjustment.

So unless you're a sadist who just wants to make everyone else worse off, it seems that selfish mining gives no advantage, unless we consider at least one of these three factors:

Transaction fees. If you mine at the same rate and cause everyone else to mine at a lower rate (because a lot of their blocks get rejected), you are still finding blocks at the same time intervals on average, but since each block takes longer in general to find, it will include more transactions and thus more transaction fees.
Difficulty changes. If the difficulty readjustment occurs as you're performing selfish mining, then of course decreasing everyone else's share of the pie increases yours.
Economic effects. With fewer bitcoins being mined, all else being equal, a decrease in supply causes an increase in price. So the bitcoins you mine are more valuable.

Am I correct in concluding that without these three effects, there is no selfish mining attack? If so, then selfish mining is not a problem in practice, at least for now. Transaction fees are minuscule compared to the block reward, difficulty retargets are infrequent, and the amount mined each day isn't really that significant compared to the total number of coins in circulation.

You're missing the main point: when a selfish miner finds a new block, he keeps it private, does not broadcast it to the network, and starts mining on top of that privately.

The rest of the network is still mining on a block that was actually already found, but not broadcast.

When the rest of the network finally finds this block, the selfish miner broadcasts his version, in an attempt to replace it.

By invalidating blocks this way a selfish miner is effectively wasting other people's cycles, and has a head start for winning the next block, because he started mining on it before the others.

Edit

Keep in mind that this practice is only successful if you're a large pool with around 25% of hashing power. Major pools of this size are closely watched and scrutinized by the entire community. Finding consecutive blocks in a row, for many times, is a strong indicator that the pool is practicing selfish mining. The community can therefore decide whether to leave the pools who are practicing this behavior.


How many api calls blocktrail allow per second How many api calls blocktrail allow per second. On official site mentioned only rate per minute(https://www.blocktrail.com/api/docs#rate_limits). Is this mean that I can make 5 requests per second(or can I do more)?

I believe it means you could do all 300 requests in 1 second if you really wanted to, and then wait 59 seconds for the next minute. Doesn't matter when you use them within that minute, just that no more than 300 are used per minute.


Stuck on blockchain 8791 - Synchronizing I don't know what's wrong with it, but I would really appreciate it if someone can help me. I've already been receiving money from this address so I really don't want to delete it. I have 3 BTC coming in.

You should backup and secure/encrypt your wallet before messing with anything. If you have a second computer, I'd recommend getting the software working there and ensure that your wallet works on that computer.

If you're running an older version of Bitcoin-Qt, upgrade to 0.8.1 or later.

Check out this other question after that.


Versions of protocols for BTC and TEST? I'm dorking around with creating a TEST transaction using libbitcoin's bx command.  Besides setting the inputs and outputs, the bx tx-encode sub-command allows one to specify lock_time and version.  Any idea where one can look to find details about what the current version is for BTC and TEST transactions?

You should use TX_VERSION = 1 and TX_LOCK = 0xFFFFFFFF for mainnet and testnet


Can someone explain to me all of the scaling proposals? What are Segwit, Segwit2x, UASF, BIP 141 and 91, emergent consensus, and core/Non-EC? All of these terms are confusing and I don't understand what they all signify. Also, could you give me a description of what has been locked in, what could have been locked in, and what can be locked in?

Segregated Witness (segwit) is a solution which redefines how the maximum block size is calculated (now called block weight) and creates new output types. These segwit output types are given a discount (compared to non-segwit output types) with the new maximum size calculation when they are spent. This means that a block will be able to have more transactions that spend from segwit outputs and thus increase the number of transactions that fit in a block. Segwit is currently not locked in nor active.

BIP 141 is the main specification for segwit. It defines the deployment parameters and the consensus rules. BIPs 143 and 144 specify the network and serialization parts of segwit. When people refer to BIP 141, they are referring to segwit's deployment parameters. These parameters specify that 1915 of a 2016 block window must signal for segwit by setting bit 1 of the block version field.

UASF and BIP 91 are methods by which segwit can be activated. When these activate, they require that all blocks must signal for segwit by setting bit 1 of the block version field. This rule remains in place until segwit becomes locked in. Any block which does not have this bit set will be considered invalid.

BIP 91 is currently active, so all blocks must now signal for segwit. It become locked in after 269 blocks of a 336 block window signaled for BIP 91 by setting bit 4 of the block version number. BIP 91 activated after another 336 block window passed.

UASF (BIP 148) activates when the median time (the median timestamp of the last 11 blocks) is after midnight on August 1st UTC. BIP 148 is currently not active. It does not have a lock in period.

Segwit2x is a proposal to activate segwit and then hard fork later to increase the maximum block weight. It contains BIP 91 and specifies that a hard fork will occur 12960 blocks after segwit activates.

Emergent Consensus (EC, aka Bitcoin Unlimited) is a proposal where the maximum block size is determined by miners. Miners choose a block size to mine at based on what they perceive the community is willing to accept. Users and miners set the maximum block size which they are willing to accept. Users and miners also set another parameter, Acceptance Depth, for the number of blocks that must be mined on top of a too large block before they accept that larger block. For example, I can choose to set my maximum to be 1 MB and set my Acceptance Depth to 6. This means that if I receive a 1.1 MB block, I will first reject it, then only accept it if 6 blocks have been mined on top of that block and the chain with the 6 blocks is longer than the chain that I am currently on.

EC does not have any activation parameters or a lock in period. It becomes active whenever a miner chooses to mine a block that is larger than 1 MB.

When people talk about "Core", they usually refer to the current status quo. However Core really also includes Segwit.


C secp256k1 : what is the purpose of secp256k1_context_randomize? In the course of studying the secp256k1 library API, I came acrosssecp256k1_context_randomize which seems similar to providing a seed to a pseudo-random generator. At the same time, the file secp256k1.h seemingly does not offer any functionality for generating random private keys, and the function secp256k1_ecdsa_sign relies on a deterministic secret (rfc 6979) rather than anything randomly generated. Now I can see the API being extended in file secp256k1_ecdh.h with the function secp256k1_ecdh which returns an EC Diffie-Hellman secret. But this doesn't seem to rely on random generation either since the scalar is provided as argument. So I am wondering, why would a user care to randomize a context, or in other words, where is randomization used with the library?

I just merged a PR by Rusty Russell that aims to explain its purpose. From the text that was added:

  While secp256k1 code is written to be constant-time no matter what secret values are, it's possible that a future compiler may output code which isn't, and also that the CPU may not emit the same radio frequencies or draw the same amount power for all values.

  This function provides a seed which is combined into the blinding value: that blinding value is added before each multiplication (and removed afterwards) so that it does not affect function results, but shields against attacks which rely on any input-dependent behaviour.

  You should call this after secp256k1_context_create or secp256k1_context_clone, and may call this repeatedly afterwards.


Why there is a huge amount of difference in price for the same coin at same time? Well, I am new to this world and trying to understand things. The main thing where I got stuck is, I realise that the same currency has different values in different places.

And in here for Ripple in India[![][2]][2]

And for bitcoins Premier Bitcoin Exchange in India

I just want to understand why such discrepancy. Any type of guide will be welcomed.

Thanks in advance

FYI : I live in India

Discrepancies in exchange rates can arise from many things, such as:

how often the exchange rates are recalculated or cached by the website
where the website gets the data from (e.g. there are a lot of different exchange platforms, the live price varies a bit between them all)
how the rate is calculated (most exchanges only support BTC/USD as fiat currency price, so any other fiat currency like Rupee or Ripple coin must be calculated using multiple conversion steps (e.g. ripple -> bitcoin -> USD -> Rupee)

Also, if you are using a website like zebpay, they set the rate themselves to include a fee, because they want to make a profit, so you can expect that rate to always be higher than the price listed on something like coinmarketcap.com. That is just the rate they sell at.


Feasibility of a "High horsepower" attack (based on difficulty -4x adjustments) This is really Part 3 of this earlier question.

Given that the QT client is hard coded to never adjust difficulty more (or less than) a factor of 4...

What realistic scenario would cause the difficulty to decrease by a factor of 4?

If the hashrate were to decrease by a factor of 4, then that means current miners are trying to keep up with a difficulty that is incredibly hard given their relatively weak horsepower.

When network hashrate drops this way, I envision:

Transaction confirmations will take a very long time
The interval between blocks would get exceptionally long
It will take a very long time until 2016 blocks are mined before the target is adjusted back.
It is relatively easy for the attacker to turn on his hardware at the 2017th block and DOS the network again.

Bottom line, I doubt the -4 difficulty would ever be reached... but could be exploited for malicious purposes.

So assuming a big loss in mining power occurs:

How much horsepower must be added and then lost for a 4x difficulty to be realized?
How long will it take a transaction to be included in a block/confirmed (worst case)?
How long will it take for the chain to return itself to normal levels?

Finally,

Are the effects of a "high horsepower user" who intentionally switches on, then off a massive mining rig enough to disrupt Bitcoin network operations?  To what end?

Disclaimer: I know that 4x is not the only disruption that can occur, since lesser magnitude attacks would be equally annoying but want to forecast worst case scenarios.

What realistic scenario would cause the difficulty to decrease by a factor of 4?

Most plausible I can think of would be a massive sustained power outage, like the 2003 Northeast blackout, covering an area with a heavy miner concentration.

  How much horsepower must be added and then lost for a 4x difficulty to be realized?

To quadruple the difficulty, you'd need to increase the network hashing rate by 4x, so you'd need to dump in 3x the current network hashing power.  But if someone has that much power to throw around, why bother with just a DOS when they could go for a 51% (or 75% in this case) attack and really screw with things?  This isn't really a relevant concern.

  How long will it take a transaction to be included in a block/confirmed (worst case)?

Worst case - never, same as currently.

Normal case - 1/4 hashing power would mean everything would run at approximately 1/4 speed, so you'd be looking at 40 minutes per block on average, but with potentially very large absolute variances.

  How long will it take for the chain to return itself to normal levels?

Until the hashing power comes back online or until the next 2016 block allows the difficulty to correct itself.  Assuming the 3/4s of the network got taken out right after an adjustment, it would be 2 months until correction.  Unless the taking-out was something outright cataclysmic, the hashing power will come back long before that.


Can a brainwallet passphrase be derived if an attacker has obtained the private keys of an empty wallet.dat file? Someone robbed me at gunpoint and took my laptop. The laptop contained an encrypted hardrive with a wallet.dat file. Both the hardrive and wallet.dat had at best weak passphrases for the encryption. I have assumed both to be compromised.

My question has to do with the one-way permutation hash function of ripemd-160 to generate both the private and public keys used in brain wallet generators.

[I am assuming that wallet generators are using one way permutations. I could be wrong. If I am then please inform me. Most wallet generators use the brainwallet.py available on github.]

If an attacker has obtained your private key can he "reverse engineer" the key to obtain the original brain wallet passphrase used when the wallet was generated?

If so I assume he can use that to bruteforce any other wallet that would use the same passphrase as a seed as mentioned in this post here:

https://crypto.stackexchange.com/questions/10246/question-regarding-multiple-sha-256-rounds-on-a-bitcoin-brain-wallet-passphrase

Sorry to hear you were robbed.

An attacker cannot reverse engineer a private key to obtain the original mnemonic phrase.

What essentially happens is just another multitude of hashes with an algorithm (SHA256). Different approaches to this are taken by different deterministic wallet generators.

As SHA256 is considered secure. So is your mnemonic phrase


ETH smart contracts v/ traditional total newb here.

I purchased some ETH on an exchange which uses smart contracts, it is in that exchange wallet.  I have another wallet which does not support smart contracts, only "traditional" ETH transactions.

Apparently the ETH is not transferable between these 2 wallets.  I am trying to find information about if it is possible to transfer ETH from a smart contract wallet to a "traditional wallet".  Is this possible?  Is there a way I can convert the smartcontact ETH back to "traditional"?

If this isn't possible then it seems smart contract ETH and "traditional" ETH aren't even the same currency anymore.  Is that the case?

I have put "traditional" in quotes because that is the term i've seen although i don't know if that is a correct term.

ETH transactions between "smart" contracts and "dumb" wallets are always possible. The fact that your wallet does not support smart contracts does not mean you cannot send funds from a smart contract to your wallet, it just means you cannot manage a smart contract from said wallet. You can still send funds back a forth between the two.


Logs from Bitcoin Core activity I can see from the date of the file (2014) that Bitcoin Core has had activity on my computer, but I am sure that I was not involved in Bitcoin whatsoever during that time. However I was in the early days. Could I have had a wallet that some hacker have emptied? This is from the debug.log (I can upload the whole file if necessary):

Committing 24771 changed transactions to coin database

ProcessBlock: ACCEPTED
2014-02-07 15:12:11 stored orphan tx 96ab951dca26ccd71......(lot of nubers)

Added 1 addresses from 60.242.28.141: 11 tried, 11727 new

received block 00000000000004dd9f5923384efd1440b.... etc....

Is this some proof that actual Bitcoin transactions of coin have been taking place, or just normal startup log text?

No, that text is not proof that there were transactions from your wallet. It just means the the software was running and those lines are normal. They just indicate that the received data from peers, but that data is not necessarily related to you.

To check if you have any Bitcoin, you can run the software and see what it tells you. It sounds like you are using an old version of Bitcoin Core, so you should probably upgrade to the latest Bitcoin Core first as it will sync much faster. Because that is Bitcoin Core, you will need to download the entire blockchain which is 180+ GB of data, but you can enable pruning to reduce the disk space used.


Is it possible (in some way or other) to expire a txout? I read Contracts: Will this be possible? where part of the question related to expiring a transaction and one of the replies said that it would never be possible since it causes problems. Unfortunately the reply didn't indicate what problems it would cause.

I can't quite understand from the question/reply whether it was a question of expiring an (unconfirmed?) transaction (which might well be problematic) or expiring a txout from a previously confirmed transaction.

Is the latter entirely impossible by any current method, e.g. scripting and/or a combination of transactions?

One way that I perceive that it might be possible (and I'm only a bitcoin newbie so please take pity on me and help me understand if this suggestion is patently ridiculous to bitcoin experts) would be to have a new bitcoin script operation that could be used in the scriptPubKey of the txout to push the 'current' time on to the stack so that it can be compared (using OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL or OP_GREATERTHANOREQUAL) to a fixed expiry time (which is in scriptPubKey and pushed to the stack by scriptPubKey) and only if the current time is less than the expiry time will the rest of the scriptPubKey allow the transaction (i.e. bitcoin payment) to be confirmed.

A note on what I mean by 'current' time...there could be a lengthy debate over the source of current time and the trustworthiness of that source but I'd propose that 'current' time doesn't truly need to be the actual current time so long as it's a reasonably close approximation in the bitcoin realm (about 10 minutes on average but maybe longer, maybe shorter). Thus it could be the timestamp of the previous block in the blockchain; that way every node (assuming no fork) will be judging the txout expiration against the same 'current' time.

An undesirable but arguably acceptable side effect is if a transaction spending the txout is submitted and confirmed in a short blockchain fork then it will get requeued on the longer fork and there is a chance that txout might have expired before the transaction is reprocessed and thus the transaction will fail the second time around.

Another subtlety to aid usability might be to offer two variants of the new 'current' time operation to mirror the two 'variants' of lock_time, one variant to push the previous block's timestamp on to the stack and the other variant to push the previous block's height on to the stack. This way a user can write transactions which are self consistent in time reference or self consistent in height reference.

Expiring a txout doesn't really make sense, since it would destroy the coins, and there is no way to destroy coins. (Coins not spoken for by any txout are contributed as fees.)

You could create a transaction with a lock_time in the future that sends the coins to another bitcoin address. If you give this transaction to a counterparty, they would then have the option to broadcast the transaction to the network after it becomes due, and it would take effect.

Before that time, you could create another transaction without the lock_time restriction, move the coins, and make the counterparty's transaction useless.


Can I save mining fees when doing transitive transactions? If I create two transactions:

Send BTC from output X to Y, no fee is attached.
Send BTC from output Y to Z, fee is attached (this depends on the previous tx).

Would nodes propegate these two transactions? Would miners mine them?

In other words, if transaction T2 depends on T1 and I want to broadcast both together - can I save some fees on T1?

Probably not. Clients can set whatever rule they like for transaction fees, but they normally adhere to the Satoshi client rules described at https://en.bitcoin.it/wiki/Transaction_fees. However, note the section on transaction priority; if you have an address holding some old coins, it's quite likely a transaction out of that address will have high enough priority for you to avoid transaction fees by default.

To implement what you describe, you would need a client that does something like hold all low-fee transactions in a small pool and watches for new transactions out of their output addresses. That's certainly possible to implement, but it seems to me that it would be the sort of service you'd pay a premium for, not receive a discount on.


How to make a homomorphic preimage/payment hash with current lightning network / Bitcoin implementations? If I remember / understand it correctly by using the mechanisms from the scriptless scripts paper we could easily create homomorphic preimages / paymenthashes.

I think this would be a very desirable property (in combination with shamir secret sharing) for example to create trustless escrow services (and not only for payment decolleration)

As far as I understand SHA-256 - which is currently used for payment hashes - is not homomorphic. In fact it is not even supposed to be homomorphic.

Does anyone see any way to gain the onchain enforcable homomorphic property with the current setup / protocol for htlcs and Bitcoin script without the necessity to change to 2party ecdsa magic / scriptless scripts or schnorr?

I fear the answer would be it is impossible but I thought I would ask since I am still a beginner with low level cryptography.

with the current system, it seems impossible to do so. The most probable protocol change/update will be after activating BIP Schnorr, when we have the chance to move away from payment_hash/preimage and can go to payment_point/secret_scalar.
Once we achieved this htlc's can be exchanged by adoptor signatures as described in this tutorial.
Those would obviously be additative since going from the group order to the group element is obviously a homemorphism so that we have (r1 + r2)*G = r1*G + r2*G where ri = preimage or secret_scalar and ri*G1 = payment_point


Can the Block Erupter be used for anything besides coin mining? Did the creators of the Block Erupter USB device have the foresight to make it capable of any other function besides mining coins?

I'd hate to think that now that Bitcoin is becoming impossible to mine efficiently, these are going to end up on the heap of truly useless technology.

Y'know?

Or perhaps is it still useful to mine non-Bitcoin coins?

They'll be useless.

But the name pretty much says it all: Application Specific Integrated Circuit.

That's why FPGA's (field-programmable gate array) were such a huge success. You'd have a circuit that you could program! While much slower the possibilities are practically endless.


How is a side-chain merging back to Bitcoin chain protected against double-spend? Where are the side-chain mining fees? I am struggling to understand the concept of "side-chains" that's discussed a lot lately, but never trully explained.

How I understand "side-chain": it's an altcoin, with a separate blockchain, with a separate PoW rules and mineres and mining rewards and so on, that has value somehow tied to bitcoin, and that can be later exchanged back "into" main bitcoin blockchain.

I struggle to understand two things though.

How will a bitcoin miner/bitcoin node check, that the side-chain transactions were correct (in the sense of "not double-spent") and that they are on the longer "altcoin" chain? Does the bitcoin node also have to download all the other chains? Isn't that strange?
How is the mining reward solved? What if this side-chain has some crazy rules (like quark) for mining 90% of the existing supply in a few days? How does the money supply even make sense with value interchangable between BTC and side-chain?

It's possible I got the basics totally wrong, but I never got past the enthusiasm to some real explanations, so I am asking here.

As Mikka explains, sidechains don't need to create their own currency, using bitcoins in the sidechain is precisely the point of two-way peg (there's no reason why an altchain with its own currency, like say litecoin or ethereum, couldn't support 2-way peg and also become a sidechain though).
Also, take into account there's several possible ways to implement sidechains. I will talk about the most basic one.

First some bitcoins are moved to a "pegging pool" for each sidechain and get locked there on a script until someone provides a scriptsig that satisfies some of them.
The user uses that "proof of suspension" to get the same quantity of btc in the sidechain. To prevent reorg risks, there must be a quieting period of X blocks in btc before the coins are accepted in the sidechain, say 100 bitcoin blocks.
After that, the coins can be send normally (or with the special rules the sidechain may have).
At some point, a new owner wants to move the bitcoins back to the main chain.
To do that he produces a "proof of burn/resumption" transaction (that needs to have a legacy format the bitcoin chain can understand). Then again there's a quieting period of X blocks in the sidechain before the coins can be claimed in the main chain.

To claim the coins back on the main chain, the user needs to provide the all the headers of the sidechain from the last time coins were withdrawn from the pegging pool to the block containing the resumption transaction (since this could easily become too long, even bigger than a whole bitcoin block, a compression mechanism is needed; I won't describe this but I'll just say that relies on "lucky blocks" and once implemented would be generally good for headers-first synchronization), the merkle path to that transaction, plus the additional X quieting blocks on top of it. This way we know how much work this chain has and that the transaction is included in that chain and buried with X blocks.
The bitcoin network doesn't need to know about the validity of the chain provided, only about the work. In that sense 2-way peg has a level of security equivalent to SPV because the chain with more work is trusted without fully validating it.

But as you say, how does the bitcoin network knows there's no other longer chain somewhere else?
It doesn't, so something else must be done to prevent sidechain miners from stealing the coins by just providing an invalid chain with enough work.
So, yes, we need yet another quieting period during which anybody can submit a "proof of reorg" with a chain longer (more work) than yours which doesn't contain your resumption transaction, invalidating your claim and making you start again.
So to steal coins an attacker must to control 51% or more of the sidechain's hashing power for the last quieting two quieting periods, the last of which could be set to days.

On the reward question, again, there's several possibilities. The simplest approach would be for the sidechain to live on transaction fees like bitcoin itself will have to do in the future. Another possibility is to distribute the fees between several future blocks to have a more predictable and constant reward. Another probably less popular approach is to have a demurrage fee on the bitcoins on the sidechain. I'm sure there will be more proposals.

You can read the original thread on 2-way peg here:

http://sourceforge.net/p/bitcoin/mailman/message/32108143/

There have also been many discussions on #bitcoin-wizards :

http://download.wpsoftware.net/bitcoin/wizards/


Can I know if a bitcoin private/public key or address was derived from another key in an HD wallet by its structure? If I have a bitcoin private key, public key or address, can I know if it is a root private key or some other part which derived from a root private key in an HD wallet by the structure of it?

To be more specific - I don't need to know any details about the parent keys or to connect a hierarchy between two keys - just to know by the structure if to treat this key/address as "unique" one in my program.

Individual address private keys begin with 5,L or K. What you're calling root private keys are actually called extended private keys and they begin with ?prv where ? is either x,z,y,Y,Z. You can see examples of those here. So that's how you tell the difference.


Indexing of transactions in the blockchain Say we have transaction T(1) from many years ago, at block height 125001; then a new transaction T(2), consuming all the outputs from T(1), comes up around block height 568720 (that's Today). There's a lot of blocks in between; many GB of data, and the nodes need to efficiently check that the outputs of T(1) were never used in all these years since block height 125001 before processing T(2). This looks like a scalability problem. How do the nodes usually do that? Do they perform a linear search? Do they have a B-tree index of all active transactions? A hash-index? Is there a more efficient way to find out? Is the blockchain structured in a way that this search is inherently trivial? What about the nodes that do not store the whole block chain history?

Thanks a lot.

Each full node maintains an UTXO set, that contains all the unspent transaction outputs. This UTXO set is built by each full node when it is initialized by going through all the blocks until the genesis block. The UTXO set, unlike the blockchain, is stored in the RAM of the machine to allow faster query (UTXOs are actually stored in $DATADIR/chainstate, but are aggressively cached in memory.) When a new block is received and validated, the nodes will remove data related to the UTXOs that are consumed and add the outputs of the new transactions to the UTXO set.


Difference between Byzantine Fault Tolerant Protocols and Byzantine Agreement protocol (i.e., BA*)? What is the difference between Byzantine Fault Tolerant Protocols and Byzantine Agreement protocol (i.e., BA*)?

Is it just a naming convention or both concept differs fundamentally?

Nathan Aw

There are many problems in the family of "Byzantine" questions with slightly different names and all related to each other in various ways. Generally, the problem concerns a network of nodes all connected with all, some of which are honest and some of which are adversarial, i.e., can behave arbitrarily, even maliciously and send different data to different peers or refuse to send data altogether. Each of these nodes have some "input", potentially different for each, and they want to agree on a common view. The "input" can be the set of new transactions to confirm in the case of bitcoin, for example.

The canonical problems in the space, which are equivalent (if you can solve one, you can solve the other), are formulated as follows:

The Byzantine Agreement Problem. A group of nodes needs to agree on some value. The protocol needs to (a) terminate within finite time, (b) have all honest nodes reach the same result, and (c) the result reached must match the input of one of the nodes.

The Byzantine Generals Problem. A group of nodes has a designated "leader" called a "general". The leader has an input value and the rest of the nodes need to agree on a value. The protocol needs to (a) terminate within finite time, (b) have all honest nodes reach the same result, and (c) if the leader is honest, then the value agreed by everyone should be the leader's value.

These problems were put forth by Lamport in his seminal paper.

These problems can be modified to allow for less connectivity or to allow for failures that are not byzantine (i.e., do not allow for malicious intelligence, just failure that isn't trying to subvert the system actively). You can also add digital signatures to the mix to make the problems easier.

In bitcoin's case, the problem solved is a harder variant; anonymous Byzantine agreement. In this case, the number of parties can change arbitrary and the parties do not know who is sending each message. The solution to this is to use Proof-of-Work.

To answer your original question about Byzantine Agreement versus Byzantine Fault Tolerance. Broadly, these titles refer to the same problem of agreement. However, more specifically, BA is used to refer to the specific problem of reaching consensus about a decision under byzantine settings; while BFT refers to designing any generic protocol (not necessarily requiring agreement), for example the Byzantine Generals protocol, for solving a problem under byzantine faults, i.e., faults that are malicious. The generic problem of BFT and the problem of BA are equivalent - if you have agreement, you can be fault-tolerant; and if you are fault-tolerant you can reach agreement.


Input validation in transactions I'm just writing a small essay about the basics of BTC and I ran into a small problem.

I know, that there are digital signatures in our bitcoins' earlier transactions (our transaction inputs) and in the next owner's public key. How can the system verify, if the input is really from our earlier output? We can just use a random (unspent) output from an earlier block, can't we? I know that we are the next owner and our public key is in the transaction, but we can (and should) generate a a new public-private key for our next transaction, so the new private key won't match our "old" public key... What is that thing I don't know or understand?

Starting from basics, each input spends a previous output:

To spend the output, the input has to include a reference to it (called an outpoint).  This includes the TXID that included the output as well as the sequence number of that output in the transaction (called a vout for output vector).

In order for Alice to pay Bob in a pay-to-public-key-hash (P2PKH) output, Bob needs to create a private key (which he keeps secret), derive a public key, hash that public key (encoding it as a Bitcoin address), and then give that hash to Alice.  Alice uses that hash in a P2PKH output in TX1.

When Bob wants to later spend that output from TX1 (using it as an input), his computer gets the hash (address) from the TX1 output, finds the corresponding public key, inserts that public key into the signature script, then finds the corresponding private key in its secure database, and uses that key to create an ECDSA signature which it also adds to the signature script.

So only one keypair is used per output, although the same keypair may be used in multiple outputs.  (This is called key reuse, and it's discouraged to improve privacy and, possibly, security.)
(The images above are from the Bitcoin.org Developer Guide transactions section, which is under the MIT license.)


How to setup a LAN network with only one bitcoind client downloading the blockchain? I want to do the following:

I have one small server PC at home. I want to install bitcoind on that machine to download the blockchain information. Then I want this machine to accept RPC calls from my LAN network and setup all other bitcoin clients on my LAN network to use that server machine for blockchain info and transaction broadcasting.

I already setup a bitcoind client on the server with the following bitcoin.conf values:

server=1
rpcuser=MyRPCUser
rpcpassword=MyRPCPassword
rpcallowip=192.168.0.*
rpcssl=1
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
rpcsslcertificatechainfile=server.cert
rpcsslprivatekeyfile=server.pem

Note that I did follow the instruction for creating a SSL certificate.

What should I do on the client machines? I tried bitcoin-qt -rpcconnect=[server-ip] but it seemed to just start regularly continuing to download the blockchain from where it stopped last time.

Besides, is it possible to let Bitcoin Armory also use a bitcoin client via RPC instead of the one of the same machine? Or does it really require a remote bitcoind <-> local bitcoin client <-> armory setup?

You need to use connect in your configuration file, rpc_connect is something different, it means that your client delegates its commands to another bitcoind.

If one client connects normally and other clients connect to it using connect = ip.of.main.client it will work the way you want it to.

Conversely you can prevent a node from connecting to anything by using connect = 0.0.0.0.

EDIT : I understand better now. You need to use rpc_connect = ip.of.master.bitcoind on the 'slave' node, and connect = 0.0.0.0 to prevent it from loading the blockchain and you should be all set.


What is the chance of transactions being processed in different order that they are broadcast Given I want to transfer bitcoin from A to B, and then from B to C. I broadcast two transactions to the network (with the same transaction fee), in order: A to B and then B to C. Is there any chance that the second transaction gets processed before the first (and thus rendered invalid because the bitcoin has not yet arrived in B)?

The clients receiving B->C first will keep it in the memory (transaction pool) and denote is as an orphaned transaction, until they find A->B. So unless network propagation is terribly slow: no, it will not be rendered invalid.


How does Bitcoin Cash implement replay protection? Bitcoin Cash says that they are providing replay protection for their fork. How does this replay protection work?

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.
The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.
The second method uses an OP_RETURN output which has the exact string:
Bitcoin: A Peer-to-Peer Electronic Cash System

as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
Update: They Bitcoin Cash specification now requires that all transaction use the redefined sighashing algorithm as explained for the first method. This means that there is now two way transaction replay protection; transactions made on the Bitcoin ABC chain will be invalid on the non-ABC chain and vice versa.


How to send bitcoins I bought a small amount of BTC. They are sitting in an online wallet. I would like to send them to my blockchaininfo wallet. Is this the process?
1. Enter the amount to send.
2. Copy/paste the receiving address.
3. Send.
Do I need to do anything with private keys at the sending or receiving end of the process?
Thanks.

Your steps sound just fine. You won't need to worry about the private keys at the back end as your online wallet stores these keys for you (and uses them to create the transaction to move the coins from one wallet to another).

Hopefully it goes without saying that you should store your blockchain.info wallet private keys somewhere as well just in case you somehow lose access to blockchain.info.


How to calculate Tapscript sigops budget? Sigops limits have been changed to budget in Tapscript. BIP341 defines the budget calculation method as follows.

The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the CompactSize prefix). Executing a signature opcode (OP_CHECKSIG, OP_CHECKSIGVERIFY, or OP_CHECKSIGADD) with a non-empty signature decrements the budget by 50.

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#Resource_limits
This CompactSize prefix include the number of witness elements at the beginning?
For example, if I have the following 5 sizes of witness data,

compact size
witness size

1
65

1
64

1
91

3
257

3
563

The total size including the above Compact Size is 1049. In addition to this, do I need to add the number of bytes(1) of CompactSize for the number of elements(5)?
That's because the above data output by Bitcoin Core feature_taproot.py is 1050. The final budget will be 1100, which is 50 added to this.

The total size including the above Compact Size is 1049. In addition to this, do I need to add the number of bytes(1) of CompactSize for the number of elements(5)?

Indeed.
What matters is the total number of bytes of witness data for that input (i.e., all bytes subject to the witness discount). That also includes the encoding of the number of witness stack elements.


Can a shorter chain overcome a longer one? Could a dominating chain fork actually be shorter (in blocks) than its abandoned predecessor? Under what circumstances could this happen?

Background info:

Strongest vs Longest chain and orphaned blocks
How does a client decide which is the longest block chain if there is a fork?
Where exactly is the "off-by-one" difficulty bug? (timewarp info)

A shorter chain could possibly be considered the correct one, but it would be very hard to make this happen in bitcoin. I can think of two ways this could happen.

  1) Go back to the genesis block and use the time warp attack.

See this for information on how the timewarp attack works.

This would let the attacker create a very long chain very quickly, because the difficulty could be artificially kept low even though blocks were solved very quickly. However, this chain would not have nearly as much work as the main chain, and so even if it were longer, it would not be accepted by the network as the correct chain. It would also fail most wallets' checkpoints.

  2) Two blocks are solved at the last height in a difficulty period and a network fork ensues.

If there happened to be a fork in the last block of a difficulty period, then the new difficulty for the next period would be different depending on which side of the fork you were on. In this case, blocks solved on top of one side of the fork would have precedence over the other.

This isn't a case of a shorter chain being chosen over a longer chain (unless the fork gets really long), but rather two chains of the same length and one of them being chosen by the network as the correct one even if it gets seen second.


Running Multiple Full Nodes on one Host simple question. I would like to run several full nodes for Bitcoin, Litecoin, Darkcoin and so on, but don't they run on the same port (8333)? Will this just work or do I need to give them several different ports?

Cheers

You need to give them different ports. Refer to https://en.bitcoin.it/wiki/Running_Bitcoin on how to listen on different ports.


After mining for a couple minutes, I stop getting shares. Can anyone explain why this would be happening? When I restart the program I quickly get shares, then after a couple minutes it almost completely stops getting shares.

I got an answer from reddit.

"Because you're mining on a variable difficulty pool... Which means you start out mining super low diff, and then it auto adjusts to a different difficulty level so that you get X amount of shares per X amount of time.

And now for the obligatory mention of NO, if you restart the miner a million times you aren't making $$$$$$$$$$$. Low diff shares worth less than high diff ones."   - CrateMayne


Is there a pro vs con chart comparing Bitcoin's Rootstock vs Ethereum Smart Contract system? Is there a comparison chart where one compares Rootstock to Ethereum? What are the pros/cons of each system?

Rootstock's smart contract features are identical to Ethereum's, both use the EVM. Contracts on Ethereum are deployable on Rootstock, and vice versa.

They start to differ when you look at the networks. Ethereum has a main network where all the contracts run in a decentralized manner. Rootstock is a sidechain of Bitcoin, but it is not a two way peg, instead it is a federated peg with some amount of merge mining.

A federated peg means that to convert your RSK back into Bitcoin, there are federated parties, or "gate keepers," that control the conversion back to Bitcoin. These gate keepers mean the whole system is somewhat centralized. In the past I'd even heard there would be additional fees for entering back into the parent chain, I don't know if that panned out, but it is certainly possible.

It sounds like an alternative unfederated version is possible with merge mining, and it is being worked on. One thing to note with merge mining and sidechains is that even though chains are rooted in the parent chain, they are mined/managed differently and so have different security properties; most likely the parent chain will be more secure than the side/merged-chains.


Missing public key in transaction input I'm in the process of understanding scriptSigs of transaction inputs and encountered some transactions with inputs that seem to be missing a public key.

This is what I expect to see as a scriptSig. A signature and a public key.

ScriptSig: PUSHDATA(71)[3044022017e2af6e1308d431365deeb5739d41a909cf0d61a9c0e48f3ae5b0bd6544bfc5022066e73dd26d71d824552b034b322603cce8b936912b99f4f3df512e502bd7c11e01]
PUSHDATA(33)[03d7b3bc2d0b4b72a845c469c9fee3c8cf475a2f237e379d7f75a4f463f7bd6ebd]

https://blockchain.info/tx/10857ad56f1695559562af8076aea4ccba625ba79a82f75e5658c0c2fa4336c0

However, I've encountered these type of scriptSigs as well. There seems to be no public key. What exactly is happening here?

ScriptSig: PUSHDATA(71)[304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901]

https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

That input spends a pay-to-pubkey output. The output it spends from contains the public key, so it is not in the input.


Import android mobile wallet to desktop I have an android wallet (The Andreas Schildbach one).
Is it possible to import this wallet into my desktop wallet?

I would like to be able to manage my funds using my mobile or my desktop - both looking at the same wallet.

I have been digging through the files in my phone looking for a wallet.dat / .wallet but can't seem to find one.

I did back up my mobile wallet then tried importing the backup file into my desktop wallet, but this did not work.

There is no easy way to export those keys but its possible. Here's a detailed How-To. Please note that you need to root your phone to get access to your wallet file.

Edit:
I just found another interessting and easier method here, but I didn't tested this one.

Edit 2:

  I would like to be able to manage my funds using my mobile or my desktop - both looking at the same wallet.

If you dont mind using a new private key you could import a private key from your bitcoin desktop wallet, sending your bitcoins to this address for further usage.


How to import a 64-byte long private key Private keys are 256 bits (32-bytes) long, according to bitcoin wiki:
https://en.bitcoin.it/wiki/Private_key

Diamond Circle, an Australian startup, sent me a pair of bitcoin address and its private key. Blockchain.info shows that the money is still in the given address.

The problem is that the private key is 64-bytes long. It's base-64 encoded evident by the trailing ==

Since it's not in WIF, I wonder how to import it. Has anyone seen 64bit private keys before?

Taking into account that 64bytes keys are probably seed keys in bip32 format you might need to derive the key first. I modified the code to reflect that

npm install coinstring hdkey
node
var HDKey = require('hdkey')
var cs = require('coinstring')

// This is your base64 key
var seed = 'oMQqnDrGq/K6aplGroOvGPUb8cn6fazEySUTzE3QFYNDQcd13NTA+sc1R8VmLYGp6TYaCqxgSnOjIb2RA7zorw=='
var hdkey = HDKey.fromMasterSeed(new Buffer(seed, 'base64'))

var hex = hdkey.privateKey
var version = 0x80; //Bitcoin private key
console.log(cs.encode(hex, version))

It should give you the familiar WIF format private key.

5HyfJgfUm7WVgUrLuo9uwtJR6ME7MYfGRhK2aeckZRooSKYGXP8


Cryptocurrency acceptance I heard that the recommended waiting confirmation time for a bitcoin transaction is 6 blocks/ 1 hour. So a shop which lets its customer to pay in bitcoin without any waiting for confirmation would risk double spending from the side of the customer. Is this a big hindrance for bitcoin (cryptocurrency) real-life usage? If yes are there any solutions, improvements? Thank you.

In Bitcoin, it is recommended that big amount of transactions wait for 6 confirmations and smaller amounts wait for 3 confirmations.
When a seller uses bitcoins to sell he must never deliver the product with an unconfirmed tx, because since it is in the mempool it can be modified. Once a new confirmation arrives the safer it will be to deliver the product.

If you want to improve it and for example accept unconfirmed txs without fear of the double spent, you should do like what Bitpay does, have your own application to generate wallets and a transaction link only understandable by your wallet software so you can use memopool transactions.

I do not recommend you to do that, I would wait those 3 confs at least to make sure.


Why can't I withdraw any BTC from MtGox? I have a balance of just 4 BTC at Mt Gox and when I try to withdraw them I get this message: Your account is currently pending review, please visit https://mtgox.com/forms/verification

What am I supposed to do about this?  Is anyone else having the same problem?

EDIT (cannot comment or answer my own question?): Yes I created the account using Tor, and their response says that's the reason.  @Stephen Gornick you are correct, the restriction is specified when creating the account.

When Mt. Gox initiates the demand for verification your account is essentially frozen for withdrawals until you send in the required identification (color photo ID and whatever else they want) and your account gets verified.

The instructions from the link you provided will clearly state what is needed.

For example, it might state

  VALID Photo ID Proof (Identity card, license, passport,...)
  Residence Proof (utility bill, tax return, insurance,...)
  ISSUED WITHIN 6 MONTHS

For the color photo ID, even a pic of the ID taken with a phone is usually sufficient.


3 transactions sent all with a high fee and all still pending This is a joke right now because I've sent 3 payments to different addresses with high fees and all of them are pending and won't confirm.

there is a huge backlog of unconfirmed transactions, the biggest there has been. people are paying huge fees and still having to wait, just wait it out, you don't have a choice