Are sipa's standardized schnorr signatures incompatible with blind signatures? Here, sipa proposes a standardization of schnorr signatures: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki

For example, sign() returns Sig{R,s} which can be encoded with 64 bytes (R.x || s) where R.y can be disambiguated via quadratic residue.

After implementing sign() and verify() according to that document, I attempted to implement blind signatures.

However, verifying my unblinded signature fails 50% of the time because of the line return false if jacobi(R.y) !== 1 in verify(), enclosed below.

Here's my pseudocodey impl:

type Signature = { Rx: int, s: int }
type Unblinder = { alpha: int, Rx: int }
type BlindedMessage = { challenge: int }
type BlindedSignature = { s: int }

fn blindMessage(nonce: Point, signer: Point, message: bytes): (Unblinder, BlindedMessage) {
    R = nonce
    P = signer
    alpha = rand()
    beta = rand()
    R' = R + alpha*G + beta*P
    // challenge
    c' = int(hash(R'.x || P || message)) % curve.n
    // blinded challenge
    c = c' + beta
    return (Unblinder(alpha, R'.x), BlindedMessage(c))
}

fn blindSign(signer: privkey, nonce: privkey, blindedMessage: BlindedMessage): BlindedSignature {
    c = blindedMessage.challenge
    x = signer
    k = nonce

    s = k + c*x
    return BlindedSignature(s)
}

fn unblind(unblinder: Unblinder, blindedSig: BlindedSignature): Signature {
    Rx = unblinder.Rx
    s = blindedSig.s + unblinder.alpha
    return Signature(Rx, s)
}

// implemented according to sipa's spec
fn verify(pubkey: Point, message: bytes, sig: Signature): bool {
    pk = pubkey
    m = message
    P = pubkey

    (r, s) = sig
    e = int(hash(r || P || m)) % curve.n
    R = s*G - e*P

    return false if isInfinitePoint(R)
    return false if jacobi(R.y) !== 1 // <-- Fails 50% here
    return false if R.x !== r
    return true
}

Here's the test that will fail 50% of the time:

noncePriv = rand()
signerPriv = rand()
noncePub = noncePriv * curve.G
signerPub = signerPriv * curve.G
message = hash('my message')

// blind
(unblinder, blindedMessage) = blindMessage(noncePub, signerPub, message)

// sign
blindedSig = blindSign(signerPriv, noncePriv, blindedMessage)

// unblind
sig = unblind(unblinder, blindedSig)

// verify
verified = verify(signerPub, message, sig)

assert(verified)

The spec's sign() uses nonce = jacobi(y) === 1 ? nonce : curve.N - nonce to force a quadratic residue y, and I would assume my test fails because 50% of the time it generates a non-residue y. However, I was unable to figure out where and how to apply this in my blind-related code. None of my efforts had an effect on my 50% pass rate.

Andrew Poelstra suggests that:

R' = R + alpha*G + beta*G

should be put in a loop .. whenever R.x is not a quadratic residue. You can change beta and this should give you compat with sipa's scheme with no security, privacy loss or blind-sig-linkability loss


How to properly use the rpc command `listunspent` with `bitcore-lib` to create a transaction and get the transaction hash? I am trying to use the rpc command listunspent to get all the UTXOs relevant to an address, and then I am trying to pass it to a transaction, using bitcore-lib.
Below is my code:

const Client = require('bitcoin-core');
const bitcore = require('bitcore-lib');
const client = new Client({
  network: 'regtest',
  username: 'bitcoinuser',
  password: 'bitcoinpass',
  port: 18443
});

var tx = new bitcore.Transaction();

var sourceAddress = ["mwkT2k1o6k4dF7ZZQ2VBbw7VedBkQA2CBK"];
var minconf = 6;
var maxconf = 999999;
var targetAddress = "2Mw3iwZdVXjeb7BN5hWqegFs8VdfZo5Rmdo";
var privateKey = "cQqVxdtPz95monJe8QJUE4h5JVtSSAjTQ1SU6z8PL9pmFj5V7ieA";

var txns = [];
client.listUnspent(minconf, maxconf, sourceAddress)
    .then(function(help){
    txns = help.slice();
    return txns;
  }).then(function(txns){
    return tx.from(txns).to(targetAddress, 15000).sign(privateKey);
  }).then(function(result){
    console.log(result);
  });

The result is similar to the transaction object.

What I want is to receive the transaction hash, which I can then broadcast.

Note: I am trying to run my core in regtest mode, I do not want to use livenet or testnet. I have also disclosed the public and private keys, as they do not hold any real value.

The first few lines of the output looks like this:

Transaction {
  inputs:
   [ PublicKeyInput {
       witnesses: [],
       output:
        Output {
          _satoshisBN:
           BN { negative: 0, words: [ 16972032, 37 ], length: 2, red: null
},
          _satoshis: 2500000000,
          _scriptBuffer:
           <Buffer 21 02 0b 0f c0 79 9d 39 8d 83 be 39 08 2c 72 49 0a 57 00 0e c2 f5 e0 01 ab a1 ee 9b 07 19 cc bd fb e3 ac>,
          _script:
           Script {
             chunks:
              [ { buf:
                   <Buffer 02 0b 0f c0 79 9d 39 8d 83 be 39 08 2c 72 49 0a 57 00 0e c2 f5 e0 01 ab a1 ee 9b 07 19 cc bd fb e3>,
                  len: 33,
                  opcodenum: 33 },
                { opcodenum: 172 } ],
             _isOutput: true } },
       prevTxId:
        <Buffer e1 45 8a fb cd df 9b 8b aa 4c a7 a0 13 b7 f6 d3 91 87 8f a3 02 94 78 92 ef 59 03 0e 40 f5 51 00>,
       outputIndex: 0,
       sequenceNumber: 4294967295,
       _script: Script { chunks: [], _isInput: true },
       _scriptBuffer: <Buffer > },
     PublicKeyInput {
       witnesses: [],
       output:
        Output {
          _satoshisBN:

First, you need to serialize the transaction:

let txSerialized = transaction.serialize(true);

Then you can broadcast it:

client.sendRawTransaction(txSerialized, (error, response) => { if (error) console.log(error); console.log(response); });


Theoretical security of mining bitcoins Is it possible to change rules of mining bitcoin division?

rewrite P2P bitcoin client (or write maleware) which will be pretending that fake bitcoin client is legal, original client
distribute program more/less widely
then by fake client division of mining loot will be with fake/own rules (e.g. give more bitcoins to farm X, even if farm X didn't work more than others)

no changing keys
no faking difficulty level/spent time
maybe changing proof-of-work action

Yes, it is possible.
This is "hard-fork" (bitcoin with other rules) or "alt-coin" (any crypto-currency with its own rules)


Negate the need for blockchain explores and full blockchain syncing for simple queries Rather than download the full blockchain or a pruned version; would it be viable to peer-to-peer ask 'what is this block' or 'what is this tx'?

We download the full blockchain from several peers so why not ask peers for just on piece of info?

Is there a javascript/node.js library that does this?

That's exactly what your bitcoind client does. It asks for specific blocks in network calls and if you wanted to, you can create a simple client that asks only for certain tx's and blocks like you said.

That is in fact what most SPV wallets (phone-based wallets and some others) are doing. They ask for block headers only and then ask for transactions related to those blocks to prove that certain transactions exist.


Simple Address check via API So I have a wallet with thousands of addresses, I want to know how can I check the blockchain whether or not a transaction has been made to one(or another) of the addresses?

There are several API services that allow bulk address queries.

For example smartbit's API takes up to 1,000 addresses with their v1/blockchain/addresses endpoint which will return details about each address sorting by the highest balance first.

Example GET request:
https://api.smartbit.com.au/v1/blockchain/addresses/1DuMuchPBGNoi5b9JmpreZ2L5EpuMiJdyc,1N75aWck3TFPorTvSgdzLUttY8uddqTAFZ,161UqtBktXJMzcg2zxBGMiHgnVrtH78Amx,19eK34996XoXPgpranrUVSPLmkxzowt8ox

Link to API docs: https://www.smartbit.com.au/api


UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'fromSeedBuffer' of undefined I am getting Getting error at this line
var root = bitcoin.HDNode.fromSeedBuffer(seed);

  UnhandledPromiseRejectionWarning: TypeError: Cannot read property
  'fromSeedBuffer' of undefined

Here is the code snippet to generate bitcoin address:

'use strict'

var bip39 = require('bip39');
var bitcoin = require('bitcoinjs-lib');

var mnemonic = bip39.generateMnemonic();
if (bip39.validateMnemonic(mnemonic)) {
    console.log('\nThe mnemonic is \n' + mnemonic);
    var seed = bip39.mnemonicToSeed(mnemonic);
    var root = bitcoin.HDNode.fromSeedBuffer(seed);
    var dp = root.derivePath("m/140'/0'/0'/0/5");

    console.log('\nThe Address is \n' + dp.getAddress());
} else {

}

Where bitcoinjs-lib v4.0.0 and
      bip39 v2.5.0 and node v8.0

Try using the bip32 module. Also there are a few other things you'll need to fix as well. See Use BIP39 to generate BIP32 addresses. Note, this will generate a P2PKH address, see getAddress() function.

index.js:

'use strict'

var bip39 = require('bip39');
var bip32 = require('bip32');
var bitcoin = require('bitcoinjs-lib');

function getAddress (node, network) {
  return bitcoin.payments.p2pkh({ pubkey: node.publicKey, network }).address
}

var mnemonic = bip39.generateMnemonic();
if (bip39.validateMnemonic(mnemonic)) {
    console.log('\nThe mnemonic is \n' + mnemonic);
    var seed = bip39.mnemonicToSeed(mnemonic);
    var root = bip32.fromSeed(seed);
    var dp = root.derivePath("m/140'/0'/0'/0/5");

    console.log('\nThe Address is \n' + getAddress(dp));
} else {

}

Output:

$ node index.js

The mnemonic is
assume victory kiwi swarm furnace firm thumb exact dizzy crucial neglect certain

The Address is
1FYtPnUZZ2ZJL2fZ6XehGtkHfujUHkqK3T


Can we look at how long it took to solve for the most recent block in the blockchain? (and how?) For example, can we see, the latest block, somebody got lucky and solved it in 1 minute, but then the next block, nobody solved it until 18 minutes later? (and how can we see it?)

Blocks have timestamps, but they are not very accurate. The protocol rules only (roughly) require them to not be more than 1 hour in the past and not more than 2 hours in the future. At least historically, miners have used this flexibility, effectively turning part of the timestamp as an additional nonce field. I don't know if this is still common practice.
Still, this means you can't rely on block timestamps to determine when they were actually created. It is possible to run a Bitcoin node yourself, and just observe when your node learns about every block - if you have decent connectivity, it will generally be within seconds of the block being found. There are also block explorer websites that generally keep track of this information.


How does HD wallet protect its master public key? Hierarchy deterministic wallets have a master public key. I fully understand elliptic curve's concept regarding to the private and public keys.
I also understand the concept that Maxwell described here to generate new public keys without knowing their corresponding private keys by only knowing the master public key.
Based on Maxwell's idea if someone gets two of the children's public keys with some simple math can calculate the master public key which allows him to generate all of the user's future bitcoin addresses.
So my question is

Does HD wallet use the same mechanism explained by Maxwell to generate new public keys?
How does an HD wallet protect its master public key?

In typical HD wallet implementations, some kind of hash of the master public key and the sequence number of the child key is added into the private portion of each child key. This makes the interval between private keys unpredictable to an attacker who does not know the master public key and thus the interval between public keys is likewise unpredictable. With this kind of implementation, no number of child public keys will reveal the master public key and there is no way to tell that accounts are part of the same family with only public information.

You can see the scheme I designed for Ripple here.


Where can I find the current fee level for LTC? I'm currently working on something that needs to estimate the fee for Litecoin transactions. Where can I find an overview of the Litecoin fee market?

The Litecoin wiki on Fees has been last updated in Nov 2015.
The Litecoin client used to specify a flat fee rate of 100,000 litoshi/kB until about two weeks ago, which appears to have been replaced with a dust limit of 100,000, and a new default minimum of 1,000 for block inclusion.

Is there an overview where I can learn how fees work today in Litecoin?

Looking at Litecoin coming from Bitcoin, most blocks have plenty of space: right now most are between 2 and 30 transactions only. It turns out, that most transactions appear to only pay the default minRelayTxFee, which is currently set to 100,000 litoshi per kilobyte in the master branch of Litecoin.

Update: There are some changes in the Litecoin fee structures outlined in this blog post: Understanding Default Minimum Fees. In summary, the recent Litecoin Core 0.15.1 release lowers the minRelayTxFee to 1,000 litoshi per kilobyte and the minFeeRate to 10,000. Eventually, the latter is supposed to be dropped to 1,000 litoshi per kilobyte as well.


Why not retarget on every block? Should make things smoother and result in less oscillation. Is there a reason why retargetting is only every 2016 blocks?

I suppose the only right answer is "because that's how Satoshi implemented it". His reasons for doing may have included easy of implementation, easy to guarantee consistency among nodes, or little worry about instability of correction algorithms.


Why is difficulty measured in a hash’s leading zeroes? I understand how generating a SHA-256 hash containing any specified sequence requires lots of guessing and checking. The longer the specified sequence, the more rarely that it will appear.

And I understand how inserting random nonces into a block until its hash happens to begin with a certain number of 0s is a computationally expensive and ultimately random process, which demonstrates proof of work.

What I’m wondering is: why zeroes, and why leading?

Could mining work just as feasibly if the challenge were to produce a hash with, say, ends in a certain number of Fs, or has the digits 314159265358979... starting at index 32?

Or is there a technical reason why miners’ goal is to produce a hash which begins with 0s, and not any other character at any other location in the hash?

The "leading zeros" are a simplification. The difficulty is encoded as a target which is essentially a 256 bit number. Since block hashes are produced by SHA-256, they're also a string of 256 bits. If a block candidate's hash interpreted as a number is numerically smaller than the target, the block candidate is a valid block.


Electrum Seed Length I noticed that Electrum seeds are 13 words long if the wallet has been created by Electrum but if I used a random hex string to create the wallet it always was 24 words long.

So before I wrote this question, I wasn't quite sure that I remembered the number of words when using a random hex string correctly. I typed down some 32 hex digits and created the wallet. Note that for this I didn't use a source of randomness. Instead, I just thought of hex digits and typed them in. To my surprise, the seed only was 12 words long. I then sha256summed my desktop wallpaper to get a more random 32 digit hex number and was back to 24 words as a seed just like when I did a few experiments some days ago using xxd in combination with /dev/urandom.

So why the different lengths? Clearly, I'm a very poor source of entropy. So Electrum might have compressed the hex number I gave it down. But why are seeds of wallets generated by Electrum only 13 words long whereas wallets created using random 32 digit hex numbers are 24 words long? Shouldn't Electrum use a good source of entropy? Maybe even /dev/random instead of /dev/urandom xored with some stuff it finds itself and therefore create wallets with a 24 words seed?

I don't even see how 13 words are enough to encode a 32 digit hex number. You'd need to encode 256 bit / 13 = 19.69 bit in every word, so you'd need at least 2^19.69 words = 847'180 words. (If you get a different result, use the exact intermediate result.) The English language has 1'025'110 words which would be enough but that's counting words like "pneumonoultramicroscopicsilicovolcanoconiosis". Electrum only uses very basic English words of which there aren't nearly as many as 847'180.

How does Electrum even create several addresses from a single 32 digit hex number? The wallet import format this website generates if I enter the hash of my wallpaper doesn't match any of the private keys in the Electrum wallet. I'd expect the first private key to be the one generated from the 32 digit hex number I entered and all others to be generated using a deterministic key derivation algorithm.

The 13-word mnemonic is just a way to encode a 128bit number into something human-readable and memorable. The 13th word is a checksum, and 12 words would suffice to recover the number encoded. You should always generate it by truly random means to reduce likelihood of someone generating the same as you and running away with your coins.
Some more info can be found here.

The wordlist consists of 2048 words since circa Aug 2014.
If you want to know how many words you need to encode a 128bit number, you can calculate yourself.

Log_2048(2^128) = 11.63636364

The 128bit number is actually a 32 digit base16 ("hex") number (2^128 = 16^32).

I tried to replicate what you did, and used electrum wallet recovery function. When inputting a 32 digit hex number, I get a 12 words mnemonic. It would also accept a 64 digit base16 number, and then I'd get a 24 words mnemonic, which makes sense considering how it's generated. However, I'm having trouble replicating what you experienced, to get a 24 word mnemonic from a 32 digit base16 number.

Now, what is that 128number used for? It's used to generate your master private key, master public key and all the keypairs in your wallet. It's nicely detailed here.

  The total number of possible extended keypairs is almost 2^512, but the
  produced keys are only 256 bits long, and offer about half of that in
  terms of security. Therefore, master keys are not generated directly,
  but instead from a potentially short seed value.

  Generate a seed byte sequence S of a chosen length (between 128 and
  512 bits; 256 bits is advised) from a (P)RNG.
  Calculate I =
  HMAC-SHA512(Key = "Bitcoin seed", Data = S)
  Split I into two 32-byte
  sequences, I_L and I_R.
  Use parse_256(I_L) as master secret key, and I_R as
  master chain code.

  In case I_L is 0 or ≥n, the master key is invalid.


Using maxuploadtarget in Node Window Console Complete first-timer to setting up my own node here... I’ve got as far as downloading and syncing the node (on Windows PC), getting my router and anti-virus ports sorted, but want to limit my upload/download capacity for a number of reasons.
I’m trying to follow the instructions from bitcoin.org by typing in -maxuploadtarget=<MiB per day> Or -maxconnections=<num> into the Node Window Console.
I keep getting the error “Method not found” despite trying a number of different ways of typing in the command.  Do I include the “-“, do I include the “< >”, do I include “Mib”, etc.
Can someone please help what exactly I should type in for a medium quality broadband without drawing too much attention (e.g. 500 MiB?).
Thanks so much and look forward to joining the BTC network.

You can make changes in bitcoin.conf file

Bitcoin Core Config Generator (compatible with Bitcoin Core 0.20)


On public keys compression, why an even or odd y coordinate corresponds to the positive / negative sign respectively? This is a paragraph from Andreas' book on compressed/uncompressed public keys.

Chapter 4 - Section - Key Formats

  Whereas uncompressed public keys have a prefix of 04 ,compressed
  public keys start with either a 02 or a 03 prefix. Let’s look at why
  there are two possible prefixes: because the left side of the equation
  is y^2 , that means the solution for y is a square root, which can
  have a positive or negative value. Visually, this means that the
  resulting y coordinate can be above the x-axis or below the x-axis. As
  you can see from the graph of the elliptic curve in Figure 4-2, the
  curve is symmetric, meaning it is reflected like a mirror by the
  x-axis. So, while we can omit the y coordinate we have to store the
  sign of y (positive or negative), or in other words, we have to
  remember if it was above or below the x-axis because each of those
  options represents a different point and a different public key. When
  calculating the elliptic curve in binary arithmetic on the finite
  field of prime order p, the y coordinate is either even or odd, which
  corresponds to the positive/negative sign as explained earlier.
  Therefore, to distinguish between the two possible values of y, we
  store a compressed public key with the prefix 02 if the y is even, and
  03 if it is odd, allowing the software to correctly deduce the y
  coordinate from the x coordinate and uncompress the public key to the
  full coordinates of the point. Public key compression is illustrated
  in Figure 4-7

What I don't get is that bold text.

Why an even or odd y coordinate corresponds to the positive / negative sign?

For example, are all even public keys below the x-axis?

There is no such thing as a negative or a positive value when you're talking in a finite field.

For example, in Z7, the field of integers modulo 7. There holds:

0 = 7 = 14 = -7
1 = 8 = 15 = -6
2 = 9 = 16 = -5
...

So you can't say that the number 2 is positive, because it's equal to -5.

Despite that, the square root still has two solutions. For example, 3^2 = 9 = 2, 4^2 = 16 = 2. Thus both 3 and 4 are square roots of 2.

So we need a way to say which solution we want. Turns out, that when reduced to a range of 0-6, the two solutions of the square, one is odd and the other is even.


Bitcoin cash not syncing the current block I have installed BCH "Bitcoin Unlimited Cash Edition  bucash1.7.0.0". Problem is the current block is not synced in our wallet server, the server is stuck at block "635258". How to rectify this problem, please suggests me

BCH makes a hard fork every 6 months. Your node supports only the Nov 2019 hard fork. Update your Bitcoin Unlimited or it won't sync.
May 2020 upgrade: https://coinspice.io/ifp/bitcoin-cash-may-2020-upgrade/


What happens when the same wallet (private key) is used on several machines? Let's say I copy my wallet to another computer and start using it there. What happens? Can both computers send and receive payments to the same address(es) in the wallet?

A different scenario with the same results: someone steals my computer and starts using my wallet. I have a backup and start using that. Can we do it?

A wallet is a combination of private keys, and transactions that spend from/to it.
Since somewhere in the 0.3 series, bitcoin will detect transactions from a key of yours that you did not create yourself, and count them as spends.

This means that if you duplicate your wallet on several machines, they will all be able to do spends, and observe spends by others. Probably as much as you would hope for, but there are a few caveats:

The wallet contains 100 pre-generated keys to simplify backups, so the first 100 new keys used by both clients will remain the same, but afterwards they will diverge, i.e. start using different keys. You do not want this to happen, which means you will need to synchronize the wallet files at least once every 100 transactions (i.e., copy from one place to the other).
If one of the clients is not yet aware about a spend done by the other (for example, it was offline at the time of the transaction submit, and hasn't caught up with the block chain yet), it may produce a transaction that uses the same input, in other words: a double spend. The software is not able to deal with this, as it will consider its own transactions unquestionably valid. This will probably result in an unusable wallet.

In short: there are some provisions for detecting spends by copy of a wallet, but it's certainly not an encouraged or supported use case.


Can there be stale blocks in "header first" implementation? The Bitcoin developer guide mentions stale blocks as not being in the longest chain, then moves on to orphan blocks. It states you don't get orphan blocks, "and if you do" they are just dropped. But it doesn't mention whether stale blocks are also "abandoned" (for lack of a better term).

p.s. I'm thinking of using a blockchain for scores in my game, to have a universal top ten sort of thing. Any comments welcome.

Stale and orphan blocks are confusing terms with many meanings, depending on whom you ask.

If by stale blocks you mean "blocks that are on branches off the main chain, but are otherwise valid", yes, those still exist. They are inherent to proof-of-work chains, as you can't avoid the case where occasionally two miners produce a competing block. Necessarily, at most one of them can win, and the other one will become stale.

If by orphan blocks you mean "blocks whose parent header is unknown", those indeed don't exist anymore. They were an artefact of the synchronization implementation used until 0.9. Since 0.10, we only request blocks once we have validated all the headers in their ancestry, so blocks without headers known cannot occur anymore.


Bitcoin transaction no confirmation unspent https://blockchain.info/tx/9268c85e3f387e8ed98a1f1b8cd4aacececaeef9f1a0e029ca8ba12024668407?show_adv=true

This is the blockchain ID, not sure if its useful. Can someone please mine it if thats how it works

Just give it time. Eventually miners will pick up the transaction and confirm it.

Just like it takes time for a payment to post to a debit card, so to does it take time for a payment to "post" on the network.


What is the best suitable transaction fee to avoid high fees but still get confirmed? Which is the best suitable transaction or also called as the network fee that can be set in order to avoid high fees and yet get the confirmation of the transaction.

Can we say that 0.00000100 BTC is appropriate ?

First a clarification: Anyone giving a flat fee in response to this question is not giving sufficient information. Transactions are (generally) selected by fee rate. This means that besides the flat transaction fee that was included, the weight of your transaction plays a critical role:

fee rate [sats/vB] = transaction fee [satoshis] / weight of transaction [virtual bytes]

In order to get a confirmation, you need to successfully compete with the other waiting transactions for block inclusion. Depending on your time preference, you either have to place your transaction within the top 4,000,000 weight units of the block author's mempool sorted per transaction fee rate, or be willing to wait until blockspace demand cools down a bit to drop to the fee rate that you're willing to pay.

There are a number of services that attempt at predicting appropriate fee rates for various inclusion times, e.g.:

bitcoinfees.github.io
whatthefee.io
bitcoinfees.earn.com
@corefeehelper (tweets Bitcoin Core fee estimates hourly)

There are also sites that give perspective on the mempool to facility users picking their own fee rates, e.g.:

jochen-hoenicke.de/queue/#24h
https://btc.com/stats/unconfirmed-tx

Finally, there is a general lower limit, the minRelayTxFee (which despite the name is a fee rate), for which the default currently is 1,000 satoshis per kvB, or 1 satoshi per virtual byte. Sending a transaction below a node's minRelayTxFee will cause the node to drop it from their mempool instead of relaying it, i.e. such a transaction will generally never get to the miners, and won't get mined into a block even when blocks aren't full.

Conclusion: If you have a low time-preference, e.g. in the case of creating consolidation transactions, and blocks haven't been consistently full, sending a transaction with a fee rate of 1 satoshi/vB will pay the lowest fees which will still get you confirmed.


Use hdseedid to give all addresses in bitcoin I'm using bitcoin core version 0.18.1 and I'm studying Hd Wallet.
I can see the value hdseedid, and I understand that it's HASH160 of my hd seed.

Can I use this seed to retrieve all my keys?
I tried to put this value in https://iancoleman.io/ like entropia, but I don't find the same address that I can find in dumpwallet.

No, you cannot use that value for that purpose.

Bitcoin Core does not support publicly derivable addresses at all (at this point).


What is the source of initial transactions of bitcoin? Sorry, if I am wrong or silly!

It is understood that:

a) Satoshi Nakamoto sent the first transaction to developer Hal Finney on January 12, 2009, the genesis block contains 1,073 transactions and he got 50BTC as block reward, which is non spendable by design.

b) Coins are mined during block publishing.

c) A coinbase transaction must be 100 blocks deep before you can spend its outputs

d) Coins don't merge

e) For each transaction, sender should have group of input coins, whose sum should be greater than equal to sum of transaction amount and transaction fee.

What is the total amount of all those transactions and how they got BTCs for the initial transactions?

What is the total amount of all those transactions

You can see Bitcoin's genesis block here:

https://en.bitcoin.it/wiki/Genesis_block

You can easily examine early blocks by using the block height in any blockchain explorer. For example here

  how they got BTCs for the initial transactions?

Mined blocks can be empty (contain no transactions other than the "coinbase" mining reward). I guess this can be the case when the mempool is empty or when all the pending transactions therein have unattractive fees.


How can 24 words allow a user to recover a public and private key? I understand that the Ledger Nano S allows one to create a 24 word recovery phrase.

A) Why is it better to have users keep a 24 word recovery phase as backup than to keep the public and private key as backup?

B) How does Ledger decode the recovery phrase into a public and private key?

A) For each hierarchical deterministic account path ~2 (if detached) to ~4 (if not detached) billion private keys and associated public addresses can be synthesized.  If BIP 44 technology is applied to HD wallets.  The same wallet can manage multiple cryptocurrencies, see this table.

B) Take a look here that concisely shows how to recover private keys and addresses for multiple cryptocurrencies using the BIP 39 seed words found here


Redeem script for segwit addresses How does one derive the Redeem Script for the new Pay-to-Witness Pubkey Hash addresses? With existing P2SH it's revealed after providing N number of Public Keys through a createmultisig function in the bitcoin client. Is it the same, just provide a single public key through a createwitness or similar function?

Is it currently available for fiddling with on testnet?

Feb2018: an older request, I just answer it so that future research might reveal useful data :-)

To compose the redeem script for a P2WPKH, there is a fairly simple structure, I copied this mostly from here:

Start with OP_0, followed by the keyhash. Keyhash is calculated with  RIPEMD160(SHA256(public key)), similiar to "std" PKH. Do not use uncompressed pubkeys!

The P2SH redeemScript will then always have 22 bytes:

OP_0:    00
Length:  14
keyhash: (20 bytes)

The scriptPubKey is composed this way:

OP_HASH160 hash160(redeemScript) OP_EQUAL

and the address is the corresponding P2SH address with prefix 3.

Step by step explanation here :-)


How to test RBF on Testnet? I'd like to do RBF testing on testnet. I'd like to simulate a transaction with too-low fees, aka "stuck" transaction, and then RBF it in various ways.
Problem is, all testnet transactions are added to the next block due to mostly-empty mempool and 1 sat/B fee rate.
Is there a clever way to create a transaction that sits in the testnet mempool, which can be later mined after RBF?
Didn't the developers of RBF test their code on testnet?

There are 2 workarounds possible:

It takes few minutes for most of the transactions to be included in a block. So, you can prepare all the steps in advance and perform within couple of minutes before this transaction is confirmed.

Broadcast transactions with fee rate below 1 sat/vByte

Change Min Transaction Relay Fee in bitcoin.conf with minrelaytxfee=0.00000001
Either run multiple nodes on testnet with same configuration and add them using addnode or ignore this step.
Create a transaction with createrawtransaction, Enable RBF and specify fee rate below 1 sat/vByte with arguments "replaceable" : true and "fee_rate" : 0.5 in fundrawtransaction
Sign the transaction with signrawtransactionwithwallet
Broadcast the transaction with sendrawtransaction
Check the transaction details using https://chain.so/testnet/btc

Bump fee: bumpfee 42bb96fa5f5812cfd53695f679b69bccaf37fb4d49b78a650e05e0109d92f223
{
  "txid": "bac13170082c79033d37767e9180d676b05044acf90e41b1a992f76eda97f14e",
  "origfee": 0.00000526,
  "fee": 0.00005616,
  "errors": [
  ]
}


Has anyone attempted to make a working voting system using a bitcoin based system? It occurred to me the other day that the difficult problem of electronic voting could possibly be solved quite nicely using a bitcoin system. I believe it's transparent enough to be trusted. I found a few threads discussing this already.

Has any work been done in this area yet? I think it's worth investigating.

Some threads I seen are here and here

The bitcoin concept has no method to limit anything to a single entity.  I am one person yet on bitcon network I have multiple addresses,  I have multiple wallets which contain multiple addresses, I make up multiple nodes, I have multiple rigs with multiple GPU each, I use multiple IP addresses.

Everything about the bitcon network was designed to allow such a scenario to take place.  evoting requires multiple concepts which are incompatible with current bitcoin network

1) authenticate the person voting (is this person a valid registered voter).
2) keep the authenticated person anonymous.
3) ensure votes can't be duplicated
4) ensure vote count is public, verifiable, and immune to abuse by central authority

eVoting not be solved "easily" by bitcoin network.  I would say eVoating can't be solved "easily" period.  There are some very non-trivial issues with the combination of the above requirements.

The bitcoin network doesn't help to ensure that any of the 4 principles above are met.


Get single xpub key from multi signature wallet I created a multi signature wallet 2 of 3. I want to get the xpub key used to generate the addresses. As I understand all 3 public keys are used to generate the address. Is it possible to use those 3 keys to generate a single xpub key for further addresses?

No, it's not possible to get a single public seed for all future addresses.

Let's say you have three private seeds, Sa, Sb and Sc with public seeds (xpubs) Pa, Pb and Pc that generate the addresses Px1, Px2, ...

Then, the way to calculate the multi-sig addresses for a 2-of-3 multisig for these three seeds using P2SH is the following:

You create a P2SH redeem script that looks as follows:

OP_2 [Pa1] [Pb1] [Pc1] OP_3 OP_CHECKMULTISIG

Then, the "multisig address" is the RIPEMD-160 hash of that script.

Thus, to know the next address, you will need to calculate a new RIPEMD-160 hash with the script now containing Pa2, Pb2 and Pc2. There is not a multi-seed of any kind.


Can bitcoins be bought wholesale? What options are available to purchase bitcoins in bulk (e.g. a buy in the range of ten thousand dollars or more) without having to mess around with a market exchange?

How can it be determined if the price is fair?

What payment methods are accepted?

The following offer sales of bitcoins in larger quantities:

Tangible Cryptography sells coins received for its bitcoin cash-out service FastCash4Bitcoins.com
Bit-Pay Merchant Services, a merchant processor (minimum $10K transaction)


Why isnt a random port chosen for SEED node sockets? I connected a node A to bitcoin testnet (Port 18333). The node discovery happens and I see couple of connections between my node A and the seed nodes. All of the sending and receiving happens between nodes ONLY via Port 18333 (I checked this in ThreadSocketHandler)

I add another node B (different laptop hence different IP) to the bitcoin testnet. I initiate a addnode <lappyB_IP>:18333 onetry connection from A and it gets accepted. But now the port A uses to send data is chosen randomly by OS and NOT 18333. This can be checked by
getpeerinfo

We should note that both are outbound connections from A -- namely the first one is we connected to seednode and send one is we connected to another node B. How come in the former data is getting sent via 18333 (default port) but in the later OS decides to chose a different port?

All nodes are listening on port 18333 for inbound connections.  Any inbound connection will use this port.  So addrlocal will show localIP:18333.

Any outbound connection will use a random port so addrlocal will show localIP:xxxxx

So every connection is either random <----> 18333  OR 18333 <----> random.  The node that initiated the connection (out) will always use a random port.

This is how all tcp/ip web services with known ports work.  Web servers listen on port 80 or port 443, browsers use a random local port to connect to them.

Edit: Should note that port 18333 is for testnet nodes. Would be 8333 for main net.  Also if on linux netstat -ntlp or netstat -ntp will show all tcp connections


What are the key differences between factom and tieron? At a headline level, both Factom and Tieron appear to offer an identical  service: ability to use the bitcoin blockchain to publish proofs of existence in a scalable way (i.e. by multiplexing multiple events into a single transaction, and therefore reducing the cost and overhead per event).

Are there any further fundamental differences:

in terms of service(s) offered to the end users?
in terms of implementation specifics?

Factom seeks to be a distributed and autonomous protocol, like Bitcoin.  There is no terms of service. Instead, Factom uses a token (factoid) to reward servers for running the protocol.  Independently, the protocol requires users to use Entry Credits (which act like accounts) to create chains and add entries to those chains. Factoids are converted into Entry Credits.

Since Entry Credits are not tradable, and only require requests be signed with the Entry Credit Key, users can buy Entry Credits from anyone who has factoids.  A user of the protocol never has to touch a tradable token.  Entry Credits are also managed at a constant dollar value; use of the Factom protocol carries no regulatory or currency risks.

Tieron does much of what Factom does as a centralized solution.  They provide digital receipts, but you do have to open an account and agree to their terms of service.  To use Tieron, you set up an account, and pay a subscription fee.  They have no token or altcoin.  This is simply a standard service company providing data integrity services for a fee.

Full discolsure:  I am the principle designer of Factom, which also benefited from design work and technical input from Wayne Vaughan, CEO of Tieron

Updated with a bit more information


How do you find historic VWAP at a given time in a specific exchange? Suppose I want to find the VWAP of BTC-USD in a specific exchange (e.g. Bitstamp) at a specific point in time (e.g. 1/1/2013 00:00:00).

What's an easy way to do this?

VWAP isn't calculated at a specific point in time, it is calculated over a period of time (commonly 24 hours or 30 days). A "24-hour VWAP at 1/1/2013 00:00:00" is actually the VWAP over the period from 12/31/2013 00:00:00 to 1/1/2013 00:00:00.

To calculate it, you'd want to use the exchange's API to get a list of the trades that were executed on the exchange during this period, where for each trade you have the execution price and the amount of BTC traded.

You then find the average of the price, weighted by volume; that it, you multiply each price with the corresponding amount, sum all these values, and divide it by the sum of all amounts traded.

Other sources can provide you with the needed data using their API, such as http://bitcoincharts.com/.

Bitcoincharts also offers this information via its web interface. For Bitstamp data, for example, go to http://bitcoincharts.com/charts/bitstampUSD, and click on "Load raw data" below the graph. You will get a table with each interval (day by default) and its "Weighted Price" in the last column. If the default chart does not contain the date you are interest in, you can change the date range with the "Time Period" control at the top.


What is the cheapest way to deposit money into a Bitstamp account from the US? What is the cheapest way to deposit money into a Bitstamp account? They offer a number of ways, but what is the easiest for someone in the US?

I spent a long time researching this very question a while ago before buying my first bitcoins thinking that Bitstamp is the cheapest way to buy bitcoins (fee wise).  I ended up concluding that the cheapest way to deposit money in a Bitstamp account from the United States is with Ripple, which allows you to bypass the $15 wire transfer fee that it would cost to transfer money the old fashioned way.  However, I ended up going with Coinbase to buy my bitcoins rather than doing this.  I'll explain why:

In order to buy bitcoins this way using Bitstamp, the process is rather convoluted.  That alone is the first reason.  The second reason is that once I added up the fees, it was actually more expensive with bitstamp because you're not just paying Bitstamp's fees, but also the fees to transfer money into Ripple.

If you still want to do buy bitcoins using this method, here's how.

1) Setup a Ripple account.
2) Fund it with SnapSwap.  Fees:0.99% + $0.30.
3) Send the money to Bitstamp using Ripple.  The deposit money page when you're logged into Bitstamp will have the Ripple address to send money to in order to fund your account.
4) Buy bitcoins with the newly funded account.  Fees: 0.5%.

Cumulatively, the fees add up to 1.49%, excluding the $0.30 fee.  The fees that SnapSwap tack on negate the advantage of the relatively low fees that Bitstamp uses.

So if you're looking for a cheap exchange, since you live in the United States and thus cannot use SEPA, Bitstamp unfortunately probably won't work for you.  Here are your other options:

CampBX.  An Atlanta based exchange that has a fee of 0.55%.  As far as cheapest way to buy Bitcoins in the United States, this is probably your best bet.  Their website appears to be down right now, however.
Coinbase.  Not the cheapest option, but it may just be the easiest option.  That's why I choose Coinbase, I got frustrated with the hoops one has to jump through to buy bitcoins on other exchanges.  Coinbase has a 1% fee plus a bank fee of $0.15 when you're buying and selling bitcoins, the real advantage is that as far as I've been able to tell, they're the only ones that let you buy bitcoins with an old fashioned bank transfer.  The price is locked in at the time when you buy bitcoins, and you get them five business days later.

Alternatively, if you live in an area where people are selling bitcoins in person, you can buy bitcoins directly from someone who already owns them.  Localbitcoins.com is the place where you can check to see if anyone near you is selling bitcoins.


Are transaction hashes random? Why does satoshidice have to re-hash the transaction details in order to determine your "lucky" number?

Are there no publicly viewable randomized numbers or hashes that are impossible for the sender to duplicate without broadcasting the transaction?

The transaction hash is determined by the contents of the transaction.  As such the payment sender determines the transaction hash so it is not random.

But the SatoshiDICE bettor does not know the secret that SatoshiDICE will use and the result of the hash after including the secret is for all practical purposes random.

To know that SatoshiDICE didn't cheat, the hash of the secret is known to the bettor in advance and then released the following day.  So the bettor can verify that correct secret was indeed used, and with that verify that the correct payout occurred.

Since SatoshiDICE wagers are bets against the house, all that is needed is a way to determine that the house properly made each payout.  This method of using the transction hash plus secret (revealed at a later time) succeeds at providing  just that.


Unconfirmed Transactions, help please I sent some bitcoin to another adress, i paid regular fee and it already more than 28 hours that its not confirmed. Can I do anything?
Why does it need that much time to confirm?
On this page (https://bitcoinfees.earn.com/#delay) there was written like 19 hours waiting time. But nothing happened.

Here is my transaction

https://blockchain.info/tx/4c4402a5439fdfcf2cd3d9bbf0c36fbae91a3ce08504da317938eed2d1a125e1

There is not mutch you can do. The easiest solution would be to wait until the transaction confirms.

Your transaction is not eligible for Replace-By-Fee. With RBF it's possible to replace a transaction by nearly the same transaction just with increased fee. To indicate RBF the sequence of one of the inputs needs to be lower than MAX_INT - 1 (in dec: 4294967295 - 1 or in hex: 0xFFFFFFFF - 1). You can check that for your transaction here.

Since you mentioned that the transaction is to an other address of yours, you could try Child-Pays-For-Parent. This works by spending the unconfirmed transaction output in a new child transaction with much higher fees to pay for the parent transaction and its self. This depends on your wallet software.

Here would be a guide for Electrum.

I the end it comes all down to the patience you have. Your transaction will confirm eventually. I would not advice somebody without technical expertise to experiment with different wallets and export/import private keys, just because the transaction does not confirm.

Fee estimation is still a difficult topic, especially in times with many transactions waiting to be confirmed. It's nearly impossible to say that a transaction will confirm in the next 19 hours.


Is there any "added value" to run a full node behind a router or firewall? By reading different questions/answers on the bitcoin full node subject, I am still wondering if there are any "added value" in running a full node as an individual.

Most of the "everyday life" people don't know much about computing and network. They don't know anything about NAT, DHCP, router configuration, process, daemon, etc. They don't necessarily want to bother with config files, don't care about command lines or complicated options and so on. And they live and sleep very well without knowing that!

So I am wondering if there are / what are the benefits in running a full node as an individual:

benefits for the network

If I run a full node without activating NAT on my Internet access router/modem (and then not being able to accept new connexions), is it pointless? Am I doing good or bad by doing this? Am I securing the whole thing for example? Other benefits?
benefits for the individual

What are the benefits for the individual who runs a full node at home, behind the ISP router/modem? Let's take the assumption that this individual is the owner of some bitcoins (so he/she has at least a slight interest in the domain). Will he/she benefits from faster transaction for example? More secure transactions? Other benefits?

Could someone clarify that for me?

Thanks

benefits for the network

Maybe, but barely.

If your node happens to connect out to a number of reachable nodes that aren't well connected by themselves, and you have a fast connection to both, it is possible that you improve relay of transactions and blocks between them. This is unlikely to be significant on itself, as reachable nodes can typically accept many connections, so there are many chances for other nodes than yours to do this as well. However, the effect of a large number of node operations choosing to do this or not may be significant.

  benefits for the individual

Absolutely, and in my opinion, this is the only reason you should (or shouldn't) run a full node.

It makes you independent.

If you run a full node, and use it to validate incoming transactions, nobody can send you an invalid transaction. There are other ways of accomplishing the same, but they all rely on trusting other parties.

And even if you don't use it to verify incoming transactions that affect you, it makes sure that miners cannot change the rules of the network without you knowing.


Why can a 51% attacker not change the block reward? It is said that in the case of an attacker having a sustained 51% power, the attack still cannot change the block reward. Why?

My naive understanding is that, since consensus is controlled by the attacker, this suffices to push through a protocol change that changes the reward.

The main branch is the only one that can still confirm transactions, so clients
would need to update their software to stay on this (malicious) main branch.

Even you have 51% of hashpower you can not change the software on other computers to accept your blocks.


Replacing ECDSA (SECP256k1) with Schnorr signatures On March 23, 2017 the Bitcoin Core team published a technology roadmap, expressing their intent to replace ECDSA (SECP256k1) with Schnorr signatures: https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/.

Pardon my naive understanding, but we currently use ECDSA (SECP256k1) to generate public keys, and by extension- addresses. How does replacing the signing algorithm with a new signing algorithm not affect today's addressing? Does it? Where does backward compatibility fit in with this?

Schnorr will replace ECDSA, the signing algorithm, but both still use the same elliptic curve and thus the same public and private keys, etc.

Regardless, compatibility with ECDSA must be kept too even if Schnorr is used, because otherwise all old nodes would see the schnorr signatures as invalid signatures, and all old transactions would be seen as invalid by new nodes, creating a hard fork. It's likely that a new OP code would be introduced for schnorr signature checking, perhaps introduced in a new witness version, to keep it as a soft fork. If introduced, it will need a new type of address, to distinguish it from the addresses which should be checked using ECDSA. So both types of address would be compatible with all new nodes, in the same way that new bc1 native witness addresses are compatible with new nodes alongside P2SH and legacy addresses


Is a proof of work consensus mechanism that discourages mining in pools possible? Most proof of work cryptocurrencies, including Bitcoin, have most of their hashrate controlled by the biggest mining pools which significantly decreases decentralization. Would it be theoretically possible to create a proof of work algorithm that distributes the block reward to miners relative to how many shares they have submitted? Basically make it so that the algorithm itself is a decentralized mining pool.

biggest mining pools which significantly decreases decentralization

Not at all. Pools contribute to decentralization. Without pools, small miners would never be able to mine feasibly, because they would never find a block. No matter how much time they spent mining, no block = no reward. Pools allow them a fair share of block rewards proportional to their work.

Would it be theoretically possible to create a proof of work algorithm that distributes the block reward to miners relative to how many shares they have submitted

It's called P2Pool


What is Blockchains 12 word recovery passphrase process Hello thank you for looking.

I am trying to discover a simple way of creating blockchains 12 Word Recovery Passphrase, they have a so called help page on this subject which is of very little help and profoundly obscure, your help would be greatly appreciated.

Kind Regards

Richard Norman

You secret key is a set of 256 random ones and zeros (bits). This is very difficult to remember. So, we need to represent those ones and zeros differently.

Create a checksum of the private key by taking the first (entropy-length/32) bits of its SHA256 hash.
Add the checksum to the end of the random sequence.
Divide the sequence into sections of 11 bits.
Map each 11-bit value to a word from the predefined dictionary of 2048 words.
The mnemonic code is the sequence of words.

Source: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki


What is the computational power required for just verifying maybe two transactions I want to know the amount of computational power required to verify a just a couple of transactions. No mining included, just verification
can it be done with CPU or maybe even phones?

Transactions can be verified as being valid by inexpensive software, such as a cellphone.

Transaction confirmation requires a miner to include the transaction in a block. Confirmation is not done on a transaction-by-transaction basis, so "how much power to confirm just a couple of transactions" is not really a good question to ask. Instead you could ask "How much computational power do you need in order to mine a block?", with the understanding that many transactions can be included in a single block.


Validation of New Blocks Basic mining question:

Once a miner solves the block and comes up with the block hash, how are the other nodes in the network incentivized to validate that hash?

If they wouldn't validate it, they aren't participating in Bitcoin anymore, i.e. they wouldn't see new payments confirm.


P2Pool latency, should I host in a datacenter or at home? I read about latency on P2Pool being a bad thing. Is this latency between the miner and P2Pool, or P2Pool and the network, or both?

I am trying to decide if I should host P2Pool pool on one of my servers in a datacenter, or at home where my miners are.

P2Pool works differently from most mining systems - it aims to have a completed "mini-block" about every 10 seconds, so latency of the p2pool hosting server is critical - milliseconds count.

So it absolutely must be in a decent datacentre on a high-quality (aka not-cheap oversold contended junk) network, not on your home connection if you expect ever to get any mined income.

You'll also have to admin the server/os/software, apply patches and upgrades and generally maintain things which can be a full-time job.

I'd suggest you just join an existing one - find one "close" to your location - do a traceroute to it - the less hops and different networks the better.


I just buy some bitcoin and this is how I see from Electrum, what should I do now to receive the bitcoin? The first time I receive bitcoin, should I wait until it's confirmed

You don't have do anything. That transaction will confirm in due course of time. You don't have to keep electrum or even your PC running.

On average it takes 10 minutes for the first confirmation. More confirmations happen all the time as the blockchain gets extended.

Note that you bought 0.001 bitcoins. The unit of account displayed there is mbtc which is 1/1000th of a bitcoin. If you want to change it to btc you can do so via tools > preferences > appearance tab > base unit option.


How are wallets updated with new balances? Let's say I have a wallet in my computer and I create an address so another person can deposit bitcoins in it.

Then it is passed to miners and later added to the blockchain. But in the meantime this transaction was not verified.

When does my wallet is updated so the balance in my wallet and in the other person's wallet are correct?

Does my wallet (and the other person's wallet) go check if it is finished and validated?

your question is unclear on verification. I think you are asking for this process: You create an address, give it to your friend, he creates a tx, and sends it to you. At this point in time the transaction is not yet mined, but you anyhow get within seconds a message, saying someone sent you some funds.

In the background the wallet software is constantly looking for updates on the network, and here for s.th. like "my address". This eventually triggers the  "funds sent to my address" message on the wallet. At this point in time it is unconfirmed. Roughly after 10minutes it should get its first confirmation, which means it is also included in a block (and verified in all details).

SPV wallets don't do verifications in the same way as full nodes. Full nodes verify each transaction, as described here.


What is the reason for the recent drop in Bitcoin classic nodes? Was it just a VPS based ploy to temporarily fake demand for the protocol?

there is indeed speculation that only a few people are running the majority of classic nodes via aws or similiar services. a user on reddit claimed to host 800 vps classic nodes alone on aws, see https://www.reddit.com/r/btc/comments/4aka3f/over_3000_classic_nodes/d113ffi

the comment is two months old and announced that those crowdfunded nodes will go offline in mid-may, which would fit the current drop.

not sure about the fake demand part of your question, as I don't think there is anything malicious in vps nodes per se and that a good amount of core nodes are on vps too.

btw. 21.co has a couple of nice charts regarding node distribution:
https://bitnodes.21.co/dashboard/#user-agents


Why does gettransaction report me only the receiving address? Both on "send" and "receive" transactions, the command gettransaction gives me the account name, and the receiving address, ignoring the send address. Why should I care about receiving address in a "receive" transaction? I want to know the send address, of course...

"receive" --> send address, receive account
"send" --> send account, receive address

Why doesn't it work this way, what am I missing, and how can I get the send address in a receive transaction?

edit: I'd like to stress out the question about why it behaves this way? as in this comment "I don't get it: if I enter the txid into blockchain.info it tells me the sender address, since it obviously is present in the blockchain... so it's just a choice of bitcoind not to tell me?"

edit: sending back anything to the from address is totally out of the scope of the question, so it is irrelevant if they might not wish receiving anything there.

I was intending to answer another question, which was closed as a duplicate in the meantime, but I will use the case that was described there as an example to answer this question.

Assuming the transaction is in fact a standard transaction, the script does in fact reveal the sender of the transaction. According to the standard transaction description in the protocol specification the transaction has to first prove ownership of an output in order to claim it and spend it in the new transaction. The transaction that gave the sender the funds specifies the hash of a public key to which to send the funds. In this case it's the output script 1 of transaction f8c71a9f7...:

OP_DUP OP_HASH160 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7 OP_EQUALVERIFY OP_CHECKSIG

Notice the 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7 in there. That is the hash of the public key. To claim this output, and then send it to you, the sender has to provide both the public key and a valid signature. So let's take a look at the script that claimed this output:

304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb

This being a standard transaction it will conform to the format <sig> <pubKey>, so the public key is 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb. To verify this we check an see if the hashes match (python code ahead):

script = "304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb".split()
h = hashlib.sha256(script[1].decode("hex")).digest()
ripe160 =  hashlib.new('ripemd160')
ripe160.update(h)
d = ripe160.digest()
print d.encode("hex")

This should result in 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7, which is the hash we have seen in the output script of the claimed out that was finally sent to you. Notice that to calculate this we did not have to fetch the transaction f8c71a9f7... but merely relied on information you could get from the transaction that you received. Now since an address is not much more than the hash of a public key we can simply build an address from the information we have gathered so far (having the hash already we start from step 4 in the address construction):

#Prepend the Mainnet prefix
address = ('\x00' + d)
#Calculate checksum
checksum = hashlib.sha256(hashlib.sha256(address).digest()).digest()[:4]
# Build the raw address
address += checksum
# Encode the address in base58
encoded_address = b58encode(address)
print encoded_address

The encoding can be done with any base58 encoder, I used this. This should print out the address 17h6u26N2TVmoPRcvxwUdfAUjDzBJX513V which is the address that sent the bitcoins in the transaction that we were looking at all the time. So you see, the information you were looking for was in the transaction all along, but quite hidden. So given an incoming transaction (or an outgoing as a matter of fact) you can reconstruct who the sender (or receiver) was. Notice that this allows you to reconstruct the sender of each individual input, which might be multiple addresses. Simply assuming that any of the addresses signing the inputs is the sender of the transaction may or may not lead to the desired semantic result.


testnet.blockchain.info api not showing latest results? I sent a transaction to the testnet address mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH a few days ago and I have been using the testnet.blockchain.info api for a while now in my project.
It was working fine last month but now it doesn't seem to be getting the latest transactions.

This is the api call:

https://testnet.blockchain.info/multiaddr?active=mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH

and this is the same address on Blockcypher:

https://live.blockcypher.com/btc-testnet/address/mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH/

Does anyone know what the issue is?

I noticed a few weeks ago that the URL https://testnet.blockchain.info now redirects to the main BTC/BCH/ETH explorer page. The whole site has a new look, and new coins.

If you search for the address via the web interface, you can see the testnet transaction: https://www.blockchain.com/btctest/address/mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH

Given the recent changes, is it possible they just haven't yet changed over the API for testnet?


What exactly is Microsoft 365 going to support? I read an announcement that Excel in the upcoming Microsoft 365 is going to support Bitcoin "recognition" and "calculations". What does that mean?

Presumably, this means that if you type '0.5 BTC' into a cell, it will be recognized as an amount of money instead of text. (Currently, if you type '$5' into a cell, it will recognize this as an amount of money.) You will probably be able to write formulas that manipulate Bitcoin amounts, which could be useful if you wanted to sum all of the Bitcoin amounts in a column.


Is there an implemented color coin demo for bitcoin? Is there an implementation of color coins on the bitcoin blockchain yet? a demo would be great.

Probably chromawallet is the more advanced implementation. http://chromawallet.com/

I think people are only using it on testnet for now.


How is a hard fork resolved? In March 2013 there was a fork following the v0.8 release. The issue was resolved rather efficiently, as explained in the post-mortem report. However in this process there were winners and losers: the miners building on the v0.8 chain had to give up their block creation fee.

The next time there's a fork like this, it may not be so straightforward. The miners may not all agree on the proper resolution for the issue.

Is there any documented set of rules (bye-laws) explaining how such forks are to be resolved in the future?

If there's a conflict among the parties involved, who has the final say?

PS: Any comments on Bitcoin's so-called (faux) "decentralized" architecture are also welcome, given my other question has been censored. The decentralization doesn't seem to work after all, which begs the question as to what the whole point of the proof-of-work scheme is anyway.

A hard fork is by definition one that does not get solved. At least not by the rules of the system, as it is essentially an incompatibility between the rules assumed by separate nodes.

But think about what can cause such a thing:

An incorrect (=not identical to the rest of the network) implementation forks off. In this case it will always certainly be clear who is "at fault". For example, in the 0.7 vs 0.8 fork, there was a bug in the 0.7 (and older) clients that limited them in an unknown way, but 0.8 was at fault for not correctly mimicking the bug. As keeping such a weird and inconsistent limitation would hold the network back, and be risky in itself, the bug-free behavior will become allowed after may 15. However, if old full clients remain on the network after that date, they will end up on a fork, and this fork will not resolve.
Two implementations arise that knowingly implement different rules, perhaps because of ideological disagreement about what the rules should be. If both are economically significant and have significant mining behind them (which in neither case necessarily means a near-majority), this is pretty much a disaster. The incentive for consensus is huge, as disagreement effectively means granting every old coin hold to spend it once on each side.

Regarding decentralization, I think you mistake consensus for centralization. There are of course degrees, but ultimately it is Bitcoin's users who decide which rules to enforce by the software they run. However, as explained, there is a huge incentive for making sure no real disagreement arises. In some cases that may mean discussion will be needed, and an agreement has to be reached, perhaps a compromise. But it doesn't mean one party gets to control others.


BTC-E - Is there an official limit on frequency of requests that can be made? Does anyone know if there is an official limit on the number of requests that can be made to btc-e.com? I know bitstamp will ban your ip address if it detects more than 600 requests per 10 minutes. I checked the terms, FAQ, and knowledge base and searched briefly on google but did not find much.

Anybody with any experience on what is the highest acceptable frequency of requests that can be made?

Thanks!

At around 50 to 60 requests/second their host provider (I believe cloudlfare) starts to error.


Trying to access my BTC from Bitcoin-Qt wallet that is out of sync I bought BTC and sent them straight to my Bitcoin-QT wallet. Now opened my wallet (ver. 4.8.3) and it says ~29000 blocks remaining to synchronize but this is not happening even though I have 14 active connections.

I have tried accessing my Private Key through both Help>DebugWindow>Console and the version using CMD bitcoind dumpprivkey etc with both returning the error message "Safe mode: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade. (code -2)"

I don't have an encrypted wallet and just want to have access to my money.

Assuming you mean 0.8.4 ? (Or 3). Latest is 0.8.5 now but nevertheless...

What is the fastest possible way to download the blockchain?

Although I wouldn't recommend the bootstrap.dat answer because you'd need to create a new wallet for that--and eventually would likely have to resume syncing the old one anyway.

Edit: it appears I'm mistaken about the above paragraph.  The thing to know about bootstrap.dat is your client still has to verify everything that was imported over the network so it's still going to take some time. But a combination of both answers might be best. And only download from a trusted source.

Try to just get the fastest connections as per the "high bandwidth" answer.  There's really nothing much you can do in the meantime because wherever else you try to send the coins is not going to go through until the entire block chain is synced.

I've gone through this when I had to re-download the whole thing after a kernel panic -- LFMF -- don't import the private keys elsewhere before it's synced.


List transactions *relayed* by my full node? Running Bitcoin Core full node 24/7, with 70+ peer connections. Is there a bitcoin-cli command that will let me see the transactions that my full node has relayed from its SPV "clients"?

FWIW, I can use Blockchain.info to search for my physical IP address. That should show all transactions with a matching "Relayed by IP" ... but the last transaction listed for my full node is 6+ weeks ago.

Trying to be a "good full node citizen," so I want to make sure everything is working AOK.

Blockchain.info lists the first IP address it sees a new transaction from.

If you aren't the one creating the transaction, and aren't accidentally the node right in between the node that does and blockchain.info, it's unlikely that you're the first to do so. Furthermore, they may not even be connected to you the whole time.

To see what transactions are being relayed, start bitcoind with -debug=net, and look for 'inv' messages in the debug.log file.


Bitcoin Signatures are susceptible to quantum attacks - how exactly and with what practical impact? @PieterWuille  wrote in another thread:

""
The hashing algorithm is probably the most quantum-resistant piece of cryptography right now in Bitcoin. Barring any specific breaks, SHA256 and RIPEMD160 are as quantum-resistant as hash functions can be (there is an inevitable square-root speedup that applies to any hash function). Much more can be said about the quantum resistance of digital signatures. – Pieter Wuille Mar 5 at 0:03
""

I would like to ask for more precise information if possible:

Which precise parameters of bitcoins blockchain would be susceptible to quantum attacks (Pieter mentioned "signatures", but what else)? And what could be the potential impact  if those parameters (signature, etc.) were successfully attacked?  (one transaction could be blocked, the entire blockchain controlled, etc...which practical effects?)

-And what could be ways to prevent attacks on those parameters? Any ideas circulating among btc dev community on how to "adjust" those parameters?

Or is the current consensus among the community to rather wait for the world till they provide new crypto schemes which are quantum proof (for example waiting for the NIST Post-Quantum Crypto Competition) ...

thank u!

Which precise parameters of bitcoins blockchain would be susceptible
  to quantum attacks?

(1) Private Key: ECDSA is the first thing that can get vulnerable with quantum computer. Using Shor’s algorithm and Grover’s algorithm you can break the private and public key encryption. As Peter said in the previous post, hashing is Quantum resistant, so you would not make your private key vulnerable in post quantum world when providing an address. However, when a person sends you some bitcoins, his signature/public key can reveal the private key. The owner of the quantum computer can go back across all transactions and calculate the private keys from the signature provided or from the public key and control all the UTXOs from it.

(2) Mining: A classical computer need O(N) operations to go through all the nonces in order to find the solution to the cryptographic puzzle. A Quantum computer would need O(sqrt(N)) to go through the nonces. This would lead to increase in efficiency in the order of magnitude of 10^10 (Tangle whitepaper). If mining is faster with a quantum computer, it could lead to consolidation of mining power if one entity were to acquire a quantum computer while it remains out of reach of others. In that case, the owner of the quantum computer can launch double spend attacks and all other benefits of 51% attack

According to this discussion, signature will need to move to post quantum world much before quantum PoW. This is because, the rough speedup is 2^240 for signatures while it is ~2^40 for proof of work.

  What could be done to prevent attacks on those parameters?

(1) Bitcoin is more resistant to quantum computing than most of the security on which the internet relies. Moreover, if you never reuse addresses, then no one knows your public keys and thus there's nothing for a QC to solve.  For example, when you send some bitcoins to a person, send the remaining change to an account controlled by a different private key. By the time someone gets your public keys/signatures, you've already spent the funds and sent the change to an account created by a different signature. Also the crypto algorithms in Bitcoin can be changed to quantum-resistant ones (see here).

(2) Bitcoin increases difficulty by only by a factor of 4 at a given time. This means we would need a hard fork to change the difficulty to suit that of Quantum computer it the transition does not happen gradually.


Can a single wallet generate (and use) both SegWit and non-SegWit addresses? Is a Segwit wallet able to generate and use non-Segwit addresses?
I'm using Bitpay's Bitcore to create wallets and generate new addresses for the users of my platform. I'm also using Bitcore-wallet-client to sign transactions.
My users have legacy wallets right now. I intend to migrate their wallets to native Segwit, but they will also need legacy addresses so that they can receive coins from anywhere. (right?)
Is it possible to have only one wallet per user, generating both types of addresses, or will I have to manage two wallets per user?
And if I have to manage two wallets per user, utxos from one wallet won't be available to the other, obviously. What's the best way to deal with their 'split balance'? Should I orient users to send all their coins to the bc1 address of the new Segwit wallet? But then, whenever they receive funds in their legacy addresses, they'd have to transfer again to the bc1 address in order to make Segwit transactions. It makes no sense - or does it? What am I missing?

I am not familiar with the wallets generated by BitPay's Bitcore specifically, but there is no general issue preventing a wallet from generating addresses of various output formats. If BitPay's wallets can only either do one or the other that would be a local implementation quirk.
While it is possible to maintain separate wallets for each user, it is rather costly to do your accounting on-chain.
The more common mode of operations for services that take custody of user funds is to only maintain a single deposit wallet. You would then generate a new address on this "omnibus wallet" for each user deposit. Since the addresses are unique, you can use the address to tell which customer to credit in your internal accounting.
However, on the operational side, you can batch multiple withdrawals into a single transaction and even move part of the funds to a cold wallet to improve your security.


How to get senders address with bitcoinj (no duplicate)? I am using bitcoinj (java implementation). I have read many answers here but none of them answers my question.
How to get senders address using bitcoinj?

I have transaction variable tx. I can get it's hash, I have used this as well: https://blockchain.info/tx/myTXhash and it showed me the transactions. The problem is not even that web is showing me the sender.

BUT: if I use that generated .wallet file and open it with multibit (bitcoin wallet) I can see there, under transactions, from who were the money sent. That means there is a way how to get senders address, but HOW?

EDIT: I was mistaken, multibit does not know from who the money came from, I was just confused because it showed me it was sent to the right address (but that was set up by me in args).

But is there any possibility to get the message somehow from client to know if it is him who sent the money?

For future reference:
In bitcoinJ (java version) the input/output addresses of transactions are located in TransactionInput and TransactionOutput objects.

For example: for Transaction tx:

List<TransactionInput> inputs = tx.getInputs();
List<TransactionOutput> outputs = tx.getOutputs();

for(TransactionOutput out : outputs){
    System.out.println(out.getAddressFromP2PKHScript(params));
    System.out.println(out.getAddressFromP2SH(params));
}

for(TransactionInput in : inputs){
    System.out.println(in.getFromAddress());
}

Keep in mind that some transactions might not have an input address.
Here is the github description of getFromAddress() method:

  Convenience method that returns the from address of this input by parsing the scriptSig. The concept of a "from address" is not well defined in Bitcoin and you should not assume that senders of a transaction can actually receive coins on the same address they used to sign (e.g. this is not true for shared wallets).


how coin exchanges protect them self against stealing coins? Let suppose we have e-shop where you can buy with bitcoins. In this case, there is bitcoind that have locked wallet. In fact this wallet is never unlocked, because you can have another wallet on different computer with same wallet.dat file.

So in case of e-shops, even website is hacked and the hacker have full access of the server, he / she will not be able to steal any coins.

However in case of coin exchanges, there must be automatic withdrawal process. I am sure some exchanges withdraw money manually, but exchanges like Bitstamp, Bittrex, Binance, CoinExchange.io and others have such high volumes and this definitely can not be done manually.

How these exchanges protects against hacks?

Because the wallets must be unlocked, so all hacker need to do is to type bitcoin-cli send ....

If the wallet is locked, hacker might find the password somewhere on the server. Then he / she might unlock the wallet and send the coins.

Other way is hacker to "insert" his payment in payment queue and the system will send the coins for him.

Remember that bitcoind is a reference implementation, but bitcoin itself is the abstraction of it.

In production environments not always you run the same software as in a desktop.

There are other bitcoin implementations that are meant for use in production systems at scale. One of them is called bcoin by the folks at purse.io and open sourced. And there are others more even.


What is a thin client? I've heard that if you don't want do download gigabytes of data just to use bitcoin you gotta use a thin client. But what is a thin client?
What are the main advantages of a thin bitcoin client and what defines it as such?

A thin client is a program which connects to the Bitcoin peer-to-peer (P2P) network but which doesn't fully validate transactions or blocks.  That is, it's a client to the full nodes on the network.
Most thin clients use the Simplified Payment Validation (SPV) method to verify that confirmed transactions are part of a block.  To do this, they connect to a full node on the P2P network and send it a filter (called a Bloom filter) that will match any transactions affecting the client's wallet.  When a new block is created, the client requests a special lightweight version of that block called a Merkle block.
The merkle block includes a block header, a relatively small number of hashes, a list of one-bit flags, and a transaction count.  Using this information---often less than 1 KB of data---the client can build a partial Merkle tree to the block header as illustrated below.  If the hash of the root node of the partial Merkle tree equals the hash of merkle root in the block header, the SPV client has cryptographic proof that the transaction was included in that block.  If that block then gets 6 confirmations at the current network difficulty, then the client has extremely strong proof that the transaction was valid and is accepted by the entire network.

(Image taken from MIT-licensed Bitcoin.org developer documentation.  I'm also the author of that image.)
The only major downside of the SPV method is that full nodes can simply not tell the thin clients about transactions, making it look like the client hasn't received bitcoins or that a transaction the client broadcast earlier hasn't confirmed.


Does mining with multiple computers add up? Let's say I have four computers, each mining bitcoins at 5 Mhash/s. Is this the same as mining bitcoins on one computer with a speed of 20 Mhash/s?

Yes, and that'll net you around 0.01 USD worth of BTC per year (as of January 2016), assuming your power is free.


How does bitcoind find p2p hosts? I read the bitcoin references but I can't find a description regarding how bitcoin clients find other host in the p2p network.
Would you please tell me?

There are several methods for a bitcoin client to find other nodes.
First of all they save a list of nodes from previous connections.
Of course this only works when they don't connect the first time.
If a client has no IPs stored it falls back to DNS-Seeds:

Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later.

Once a client is connected to the network, it will ask for a list via the Addr-Message containing a list of IPs of known clients.
As you can see in the Bitcoin-Wiki there was another method, which is no longer used:

IRC
Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.


are individual satoshis as secure as an overall bitcoin? I don't really understand Bitcoins as well as I'd like.  I understand that eventually there will be 21,000,000 bitcoins mined.  And, I understand that each bitcoin can be subdivided into 100,000,000 satoshis.  so there will one day be 2,100 Trillion satoshis in the system.

So, Is each satoshis as secure as a bitcoin?  Or, I was imagining, that even though each bitcoin might be highly secure, perhaps a bitcoins individual subdivisions might not be accounted for so well.  Suppose one organization had a several bitcoins, but a great many of the organizations members owned various numbers of those bitcoin's satoshis.  Would they need to be extra concerned that their satoshis could somehow disappear, when they owned less than a full bitcoin?

(Does accountability begin with the satoshis, or with the bitcoin?)

When people "hold Bitcoin", they actually have access to a private key that allows them to sign for one or more unspent transaction outputs (UTXO) of the corresponding Bitcoin sum. The amounts in transaction outputs are in fact specified as a count of satoshis.

All unspent transaction outputs are tracked by each full node on the network, therefore, it is no more likely that a smaller amount is going to be forgotten rather than a greater amount. However, since transaction fees are paid for transaction size and not transacted amount, smaller amounts can have a much higher relative cost to be spent than larger sums.


Does each block contain all the Bitcoin transactions for that time period? When a miner validates a block, does the block contain all transactions in Bitcoin for that time period? So does a miner validate an individual transaction between two parties, or are they validating transactions between all the parties in Bitcoin for that time period.

When you read examples about a transaction in Bitcoin, it makes it seem like each individual transaction (e.g. 1 Bitcoin from Bob to Alice) is its own block, validated by a miner.

The process of a transaction being created and included in the blockchain is as follows:

The sender creates, signs, and broadcasts the transaction
All Bitcoin full nodes, including miners and regular users, receive the transaction and validate it by making sure it follows the Bitcoin protocol rules
Nodes temporarily store the unconfirmed/yet-to-be-mined transaction in a database called the "mempool" (each node has its own copy of the mempool)
Miners combine many transactions from their mempool into a single block. They will put as many transactions as they can fit into a single block (based on the Bitcoin protocol rules)
Miners begin hashing the block until they come up with an acceptable hash (this is proof-of-work mining)
Once they have successfully "mined" the block by getting an acceptable hash, they broadcast the block to the network
All full nodes receive the block and check to make sure the block and the transactions within it are all valid with regard to the Bitcoin protocol
If the block is valid, nodes add it to their copy of the blockchain. They also remove the transactions within the block from their version of the mempool
Non-mining nodes sit and wait for more transactions/blocks to come in for them to validate. Mining nodes go back to step 4, bundle more transactions into a new block, and repeat the mining process


Is it safe to say that all bitcoin that is mined is staying in the bitcoin adresses that is generated between 2^0 and 2^256? We know that bitcoin adresses are generated with a 256 bit number(the amount of multiplication  that is used on secp256k1 curve). So there can be 2^256 addresses at most where all the bitcoin sits on. Can we say that if one can somehow get all the bitcoin addresses(I know it is not doable), you get all the bitcoins that is generated/mined ?

First of all, since a single key can be represented by tons of different address types, let's assume what you meant to ask is about private keys. As @dave_thompson_085 points out, most addresses are actually limited to a 2^160 space by a RIPEMD hash. So that number may be closer to the actual amount of keys you'd need to sweep "all" the bitcoin.
But you are basically correct, the security of ECDSA is based on really big, really random numbers that are so big and so random no one will ever generate the same number as you.
A few details though, from my understanding:
The order of the curve is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
ref 1
ref 2
So there is a slightly lower number of possible private keys than just 2^256
Also, not all Bitcoin outputs require a single key for spending. There are multisig scripts and more complicated spending policies. Assuming you had "all" the private keys and could look them up in a practical way, I suppose you could assemble multisigs where necessary. But that's not all - plenty of transactions are HTLCs which require the pre-image to a hash in addition to a valid signature to spend.
Another thing is that some Bitcoin addresses really are black holes (burn addresses). If an address represents a point that is not on the secp256k1 curve, then there is literally no private key.
Some Bitcoin may also have been sent to unrecoverable scripts like OP_RETURN or scripts that require finding a hash collision.


Bitcoins stuck in phone based wallet So here is my situattion:

A while back I have purchased as and experiment some cloud mining, I ended up getting about $70 out of it. Anyway I use the official Android bitcoin app:

https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en

I have it backed up. And now when I try to restore it, the app just freezes at certain point. At the beginning it is 8 months behind, and as transactions start to appear in it, under each transaction there is alert basically saying that due to the fact that these transactions send to multiple addresses at once that app may become slow over time. And boy.. are they right. After it reaches certain point the transactions don't even  show up anymore, and I can't seem to be able to send any bitcoins to some other adress before it is fully synced.

So my question is, can I maybe take the back up file and restore it to different wallet app (maybe one of the online based, or even some PC based  one (Ubuntu)), as my guess is that my phone just can handle it (tried HTC ONE m7 and some shitty Sony Xperia). If so, how would I do it? Or all I can do is just keep on waiting? Or any other way to get my bitcoins out of that wallet, and just to forget about that wallet?

Actually, bitcoins are not IN a wallet. They are and will always be 'ON' the blockchain. The blockchain says how many bitcoins each address owns. Our devices merely save our private keys (you could say, our passwords) for us, since we can't really remember those very well.

If you can extract the private key from your wallet file, you can simply import the private key in pretty much every bitcoin wallet there is out there and claim the coins stored on the addresses.

(Keep your file(s) safe, because anyone with the private key can claim the coins and send them to another address you do not have the private key for!)


Is it true to say 51% of nodes should validate a transaction? I've read some articles about the bitcoin network, some of them say it is necessary for a transaction, before adding to blockchain, to be validated by more than half of all nodes in bitcoin network. Is my understanding true? If yes, is it true to say that after exactly 51% of nodes have validated the transaction, it will be added to blockchain?

No, it is not necessary for any node validate a transaction before it is included in a block and thus added to the blockchain. A transaction can be included in a block without being validated, but doing so risks the transaction being invalid and thus making the block invalid. This has happened several times in the past; miners will make their own transaction and include it in their own block without broadcasting it to the rest of the network.


For maximum mining performance, is it better to minimize latency from the mining rigs to the p2pool server, or from the p2pool server to the Internet? I'm setting up a p2pool server to mine Scrypt-based coins on.  Mostly just for myself, but occasionally some friends will jump in.  I'll mostly be mining newer coins with very low difficulties.  I'm wondering whether I'd get better results by:

Locating the server at home with my mining rigs, which would give extremely low latency from the rigs to the p2pool node, but higher latency from the server to the internet through my crappy home DSL connection.

or

Locating the server in a datacenter, which would give higher latency from my mining rigs to the p2pool, but lower latency from the p2pool server to the internet.

I guess the question boils down to "For maximum mining performance, is it better to minimize latency from the mining rigs to the p2pool server, or from the p2pool server to the Internet?"

Are you aware that there is no 2nd option in your post? :)

Despite that, your second 1. option is better. If connection to the miner is one of the poor quality ones, p2pool will just adjust the share diff accordingly, decreasing the theoretical penalty.

However, if connection from your pool to the Internet is poor, it doesn't matter if you find block or not - it can be orphaned anyway, especially with altcoins with wrong low block time.


Transaction still unspendable with CLTV Previously I generated tx with CHECKLOCKTIMEVERIFY
Here is the transaction https://tchain.btc.com/bb1415c166fd9f767c06d34d539f4b110ef4445f74a76c5ffad1ded33032e872

It lock funds before block 1442909.
I create a new spend transaction.

When I trying to sign it:

bitcoin-cli -testnet signrawtransactionwithwallet "020000000172e83230d3ded1fa5f6ca7745f44f40e114b9f534dd3067c769ffd66c11514bb0000000000ffffffff01443dd200000000002676a92103e8546cfe53ca9014f6a352bc2e5c1f7cec1f5b344c73d4db3ed3b8f075d5c9ef88ac00000000"
{
  "hex": "020000000172e83230d3ded1fa5f6ca7745f44f40e114b9f534dd3067c769ffd66c11514bb0000000000ffffffff01443dd200000000002676a92103e8546cfe53ca9014f6a352bc2e5c1f7cec1f5b344c73d4db3ed3b8f075d5c9ef88ac00000000",
  "complete": false,
  "errors": [
    {
      "txid": "bb1415c166fd9f767c06d34d539f4b110ef4445f74a76c5ffad1ded33032e872",
      "vout": 0,
      "witness": [
      ],
      "scriptSig": "",
      "sequence": 4294967295,
      "error": "Locktime requirement not satisfied"
    }
  ]
}

I got "Locktime requirement not satisfied" ? The height of blockchain now is 1,442,912

What I'm doing wrong?

Bitcoin Core does not support signing scripts with CLTV instructions.

It only supports:

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

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

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

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

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


Why bitcoind/bitcoin-qt is imposing transaction fee? bitcoind is imposing a transaction fee of 0.0001 BTC forcefully even though I have set "transaction fee" to 0. Is it possible to transfer BTC to an address without paying a fee? If so, how?

Upgrade to Bitcoin version 0.9 or later which removes the minimum relay fee. Just be warned -- the lower the fee you set, the longer it can take for your transaction to be confirmed. Zero-fee transactions can take days.


why is the header for the JSON RPC interface text/plain? vs application/json? the bitcoin core docs call out that RPC HTTP requests must include a Content-Type header set to text/plain and all the example commands confirm this header. why is it text/plain instead of application/json?


How does blockchain.info get miner revenue? In the stats page of blockchain.info, I see the revenue of miners is $1,680,297.91. As I understand, its the total money that people have spent on buying their miners. But, i doubt that since its a bit too small compared to the total revenue of Bitcoin market. So I have some questions as following

What is the meaning of that number?
How does blockchain.info compute it? Will it be updated frequently?

This number means something else then you expect. It is the value of the reward for the miners, so exactly the revenue.

I will show you how this number is calculated:

There are (currently, may differ in the future) 144 blocks mined. That means that there are 144*25 = 3600 bitcoins awarded to miners. The value of 1 bitcoin is  $465.07 USD according to the statistic page. The 3600 bitcoins have a total value of $1,674,252 USD. Add a little of the transaction fees (13.41473297 BTC, which is 0.37% according to the statistics page) and this will results in the 1.68 million USD revenue.

Blockchain can simply calculate all these things from the different blocks, because everything is also on the site.


Dynamic PHP Array used in sendmany bitcoin command issue I have following problem with dynamic array be used in sendmany transaction in bitcoin engine, problem described in code comments.

step 1 create array
step 2 inserting values to array
step 3 print an array to check the result which is correct
step 4 sendmany (here is a problem) see below

<?php
//step 1 create array
$to = array();
//step 2 inserting values to array
while ( $row_users = mysqli_fetch_array($getting_allowed_users) )
{
          $to[] = array($row_users['user_bitcoin_wallet'] => $currency);
}

//step 3 print an array to check the result which is correct
print_r(array_values($to));

//step 4 sendmany (here is a problem)

// if I do it that way sendmany is only sending to first wallet which is indexed [0]
// I cannot to foreach as php  code structure is not allowing {} inside the command
$bitcoin->sendmany($BuyerAccount,$to[0]);

//Question: How I can display all the values from my array in following place
$bitcoin->sendmany($BuyerAccount,ALL THE VALUES);

//example
$bitcoin->sendmany($BuyerAccount,"walet1"=>0.1,"walet2"=>0.1,"walet3"=>0.1.....);
?>

Have you tried:
$bitcoin -> sendmany($BuyerAccount, $to);?
Bitcoin API states <fromaccount> {address:amount,...} [minconf=1] [comment] as parameters, so you don't have to iterate - pass the whole array.
If it doesn't work somehow, you can also prepare request by yourself for RPCClient. This is example for sendfrom:
                $request = '{"method":"sendfrom","params":["'.$params[0].'","'.$params[1].'",'.$params[2].','.$params[3].'],"id":'.$currentId.'}';


how to embed coin prices of my choice in my website sorry for bad english, let's just say i want to embed specific price of coin for example ethereum and bitcoin $20 price in my website, in other words it shows $20 rate of btc and eth on my website not whole coin price.

You can use any exchange api or cryptocurrency market data api such as:

https://coinmarketcap.com/api/

Example:

https://api.coinmarketcap.com/v2/ticker/1/?convert=USD returns the following:

{
    "data": {
        "id": 1,
        "name": "Bitcoin",
        "symbol": "BTC",
        "website_slug": "bitcoin",
        "rank": 1,
        "circulating_supply": 17193862.0,
        "total_supply": 17193862.0,
        "max_supply": 21000000.0,
        "quotes": {
            "USD": {
                "price": 6963.44528122,
                "volume_24h": 3783503583.4896,
                "market_cap": 119728517210.0,
                "percent_change_1h": -0.51,
                "percent_change_24h": -1.1,
                "percent_change_7d": -14.16
            }
        },
        "last_updated": 1533575182
    },
    "metadata": {
        "timestamp": 1533574768,
        "error": null
    }
}

You can then access the price using javascript and calculate how much $20 is worth.