text:
How do you derive the private key from two signatures that share the same k value?
I wrote my own ECDSA signature algorithm just for the purpose of creating unit tests.
With it I created two signatures which went into transaction 56ec7ca7df..., sending from 1GXFXm3es.... These signatures used the same k values, although k values must never be reused.
Later on, someone was able to steal 0.0016 btc from 1GXFXm3es.... and send them to 17WRjamox6VhTUaHsTWfFnMNDYHvwCtWio.
So someone must be monitoring the blockchain for mistakes like this and stealing funds if they encounter them.
How do you derive the private key from two signatures that share the same k value?

For some more info about how to find k values while taking into account transaction malleability, see my answer:  https://bitcoin.stackexchange.com/a/35850/6091

ECDSA signatures are pairs (r,s) where r=(kG).x mod n, and s = (m + rx)/k mod n, where x is the secret key, k is the random nonce, and m is the message.
If you have two s values s1 and s2 for the same secret key and with the same nonce k (and thus the same value r), the following holds:

s1 = (m1 + r*x)/k
s2 = (m2 + r*x)/k

From that we can derive:

s1 * k = m1 + r*x
s2 * k = m2 + r*x
(s1 - s2) * k = m1 - m2
k = (m1 - m2) / (s1 - s2)
x = (s1 * (m1 - m2) / (s1 - s2) - m1) / r
x = (m1s2 - m2s1) / (r*(s1 - s2))
(all mod n)

So not only did you make it trivial to detect signatures with the same nonce (they have a recognizable r value), there is a trivial formula to compute the private key once someone sees two signatures.
This kind of attack has been known and actively exploited on the Bitcoin network since at least 2013: https://bitcointalk.org/index.php?topic=271486.0 . Don't reuse k values. Use RFC6979 to deterministically but securely generate them.
Also note that it's not sufficient that the nonces are different. They also can't be related in a known way. For example, you can't use k for one signature, and k+1 for the next work.

Thank you. I wanted deterministic signatures so I just entered a fixed number for my unit tests. But RFC6979 is a much better solution.

I ended up implementing RFC6979 and it made interacting with the signatures much easier.

If you know two signatures about one random number, you can calculate the private key.

It's simple!!
1.
https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac?format=hex
2.
https://2xoin.com/getRSZfromRawTX/
"sigR": "00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6",
"sigS": "59a23e4521da413a2c7d0f9a668eedc2e5eac88347c67c48dcca0128fda1cad7",
"sigZ": "4b2cdf712dc7d3fac8e7ed63b3a2e806556ca7d5c30ed5f4b34dbb2a12b0c18f",
"pubKey": "02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f",

"sigR": "00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6",
"sigS": "39d5e056231a5823dc0957e3d0fa3923ce71f781ad67140a6433fe6829bdf811",
"sigZ": "1cd506860c52d7e042f56b33a856b94fdefa3bcc808a06dd3b82619db2c01969",
"pubKey": "02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f",

possible k  = 539
Public Key: C 02db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6
possible k  = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0363c08
Public Key:
C 03db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6  !!!!!
Privkey = 79c7f119413edb1a9a9a2ea655196e0e3b6380b6d612dcc69c7c143816c8ef29
C L1JSKFNgNh7FyNw642ofHzivm8ua4EqpEqZyVQ8rmC6q6S9RgzYj
Here is the answer to your question!


text:
How do I generate the Bitcoin Cash hash preimage?
I am attempting to manually generate a signed transaction which is to be sent from my address 1GiJZtN7wjUuL4V5i7ZYYDAvFtqi5AhCDr which is bitcoincash:qzk9nxh6qpd9yt3hvv6vvun78s834f3escdhu2vdjp in the new address format. I am using an uncompressed public key in this transaction.
I have the following unsigned Bitcoin Cash transaction. How do I find its hash preimage which is the hash used in the signing of this transaction?

0100000001fb4a8e5c7ac5311f32fbe127f031134ee3e7490f3308ca19c567f78d6aa96d770000000000ffffffff0100a00700000000001976a914a8e181e0847b495df439066ca8fb36ce093692be88ac00000000

Breaking it up, it looks like this:
01000000 - nVersion
01 - num of inputs
fb4a8e5c7ac5311f32fbe127f031134ee3e7490f3308ca19c567f78d6aa96d77 - txid (little-endian)
00000000 - vout
00 - size of sigScript
ffffffff - sequence number
01 - num of outputs
00a0070000000000 - amount (hex, little-endian)
1976a914a8e181e0847b495df439066ca8fb36ce093692be88ac - scriptPubKey
00000000 - timeLock
I am attempting to consume output 0 from the transaction with txid: 776da96a8df767c519ca08330f49e7e34e1331f027e1fb321f31c57a5c8e4afb,
The scriptPubKey for that transaction's output 0 is:
1976a914ac599afa005a522e376334c6727e3c0f1aa6398688ac

The value of the received output is 0.005 BCH
The transaction I am attempting to consume can be found here:
https://bch.btc.com/776da96a8df767c519ca08330f49e7e34e1331f027e1fb321f31c57a5c8e4afb
And the rawtx for the transaction I want to consume is here:
https://bch.btc.com/776da96a8df767c519ca08330f49e7e34e1331f027e1fb321f31c57a5c8e4afb.rawhex
Can anybody help me?

Bitcoin Cash uses BIP 143 for signature hash creation.
From the BIP:

  Double SHA256 of the serialization of:
     1. nVersion of the transaction (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
     4. outpoint (32-byte hash + 4-byte little endian)
     5. scriptCode of the input (serialized as scripts inside CTxOuts)
     6. value of the output spent by this input (8-byte little endian)
     7. nSequence of the input (4-byte little endian)
     8. hashOutputs (32-byte hash)
     9. nLocktime of the transaction (4-byte little endian)
    10. sighash type of the signature (4-byte little endian)

So the hash preimage will look like this:
01000000be16f25831b40c713fed6627e39aa7717170f5cdd62c765bd4882abbefdaa50e3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044fb4a8e5c7ac5311f32fbe127f031134ee3e7490f3308ca19c567f78d6aa96d77000000001976a914ac599afa005a522e376334c6727e3c0f1aa6398688ac20a1070000000000ffffffffc8e2e71fe663fc91d7aa109feffee0f1497862af35525f68f500cbd55f6ed6620000000041000000

And here is its breakdown:
nVersion: 01000000
hashPrevouts: be16f25831b40c713fed6627e39aa7717170f5cdd62c765bd4882abbefdaa50e
hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
outpoint: fb4a8e5c7ac5311f32fbe127f031134ee3e7490f3308ca19c567f78d6aa96d7700000000
scriptCode: 1976a914ac599afa005a522e376334c6727e3c0f1aa6398688ac
value: 20a1070000000000
nSequence: ffffffff
hashOutputs: c8e2e71fe663fc91d7aa109feffee0f1497862af35525f68f500cbd55f6ed662
nLocktime: 00000000
sighash: 41000000

I get the "hashPrevouts" to be:
"be16f25831b40c713fed6627e39aa7717170f5cdd62c765bd4882abbefdaa50e" which is sha256d("fb4a8e5c7ac5311f32fbe127f031134ee3e7490f3308ca19c567f78d6aa96d7700000000").
Who of us is right?

Hmm, yes, you're right. I will edit the answer

What exactly does this value of the sighash field mean?

Sighash indicates what data exactly is being signed. It's a type indicator.

source: Stack Exchange

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

sort: votes


text:
System requirements for running a Bitcoin Core node on testnet
What are the minimum systems requirements for running a Bitcoin Core full node on testnet?

According to https://tbtc.bitaps.com/ today it's ~20GB. The RAM usage is similar to that of running a Bitcoin node on the main net.

Nice. Thank you. I just need to figure out how much RAM it consumes then :)

A testnet node will use about the same amount of memory as a full node.  There are various configuration parameters to reduce the memory usage, at the cost of some performance.

@NateEldredge: But there are significantly fewer transactions on the testnet. Does the RAM usage not scale with the number of transactions?

@ThorkilVærge: AFAIK, no, it doesn't.  A major part of the memory usage in Bitcoin Core is caching previous transactions, so that they can be used to verify future transactions that spend their outputs.  The cache size is set statically, and I believe the default is the same for both mainnet and testnet.  So on testnet, you'll use the same amount of memory, but your cache will hold transactions going back further in time.  This does mean, though, that you should be able to lower the cache sizes for testnet in your config file without a significant performance hit.

I ran both instances on a machine and compared their RAM usage using htop. The test net and main net use an equivalent amount of RAM, within 30 % of each other.

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


text:
How to delete wallet without deleting blockchain
I am registering some addresses as watch only addresses and I would like the ability to reset my wallet without having to sync again. Can I just delete my wallet.dat?
I use Bitcoin Core version 16.1.
This wallet does not handle any private keys with a non-zero balance.
Warning: Deleting wallet.dat will make you lose your Bitcoins if your wallet has a non-zero balance!

Yes, you can just delete the wallet.dat

As Raghav already commented:
Yes, you can delete the wallet.dat file as long as you don't have any private keys in it. Once you restart Bitcoin Core it creates a new and wallet.dat.

as long as you don't have any private keys in it with a non-zero balance which you don't have tested backups of

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


text:
How are Bitcoin Signed Messages generated?
Ledger Nano S and other pieces of Bitcoin software and hardware can sign messages using the private key associated with an address.
Doing this, I get the following output:
-----BEGIN BITCOIN SIGNED MESSAGE-----
Test
-----BEGIN SIGNATURE-----
1BqtNgMrDXnCek3cdDVSer4BK7knNTDTSR
ILoOBJK9kVKsdUOnJPPoDtrDtRSQw2pyMo+2r5bdUlNkSLDZLqMs8h9mfDm/alZo3DK6rKvTO0xRPrl6DPDpEik=
-----END BITCOIN SIGNED MESSAGE-----

What exactly is being signed? How is the signature generated? What is the hash preimage that goes into the ECDSA signing algorithm?

There docs and sample code widely available. Most bitcoin full node implementations also have a verifymessage function that you can look at.

So I need to prepend "\x18Bitcoin Signed Message:\n" + chr( len(message) )  to the message. What encoding is used to transform the string into a byte array, UTF-8?

The message that is signed is prepended with
"\x18Bitcoin Signed Message:\n" + compactSizeEncoding( len(message) )

\x18 is Python syntax for unicode character 0x18. This new text string is then converted into a byte array by interpreting the string as UTF8. This will give you the correct hash preimage which is:
SHA256(SHA256(utf8.to_bytes("\x18Bitcoin Signed Message:\n" + compactSizeEnc( len(message) + message )) =
559766ea41f2bc4125e5449200dbf7e902b724b66104820ca5b7fc59f30a19e0

You can see a Python code example here. The function msg_magic generates the hash preimage from the message. This Python code example does not correctly implement compactSizeEnc, however. So it only works with a message length up to 253 bytes.
The correct way of handling compactSizeEncoding is documented here.

The message that was signed is "Test". Will use https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-message-validate command line interface below.
As you can see, I clearly do not have the private keys nor did I have access to the BTC blockchain, but I can validate the message was digitally signed by a person in control of the private key for BTC address 1BqtNgMrDXnCek3cdDVSer4BK7knNTDTSR without the need for possessing the associated BTC public key.
% echo -n "Test" | bx message-validate 1BqtNgMrDXnCek3cdDVSer4BK7knNTDTSR ILoOBJK9kVKsdUOnJPPoDtrDtRSQw2pyMo+2r5bdUlNkSLDZLqMs8h9mfDm/alZo3DK6rKvTO0xRPrl6DPDpEik=
The signature is valid.
Result when the message is changed:
% echo -n "Tested wrong message" | bx message-validate 1BqtNgMrDXnCek3cdDVSer4BK7knNTDTSR ILoOBJK9kVKsdUOnJPPoDtrDtRSQw2pyMo+2r5bdUlNkSLDZLqMs8h9mfDm/alZo3DK6rKvTO0xRPrl6DPDpEik=
The signature is not valid.
Result when the wrong public address is applied:
% echo -n "Test" | bx message-validate 1FZHv7fubXkMcgbDBUeehgPf28cHP86f7V ILoOBJK9kVKsdUOnJPPoDtrDtRSQw2pyMo+2r5bdUlNkSLDZLqMs8h9mfDm/alZo3DK6rKvTO0xRPrl6DPDpEik=
The signature is not valid.
This is the magic of Internet money. The math is documented a bit in the Andreas' Mastering Bitcoin Book. Also see How is Public Key extracted from (message, digital signature, address).

Yeah. It is pretty cool that you can validate a signature with only an address, you don't need the public key.


text:
Litecoinj transaction sent to unknown address
I have used litecoinj-core-0.15 to generate a transaction to address MD1AYTZnTtGKQToj2LTD7qLsSzrqcdXr9J.
Litecoinj generated a transaction with two outputs. The first one (to LaPJ9TfBr6E2MSRa4t1MMhFPQAue4osUn8) corresponds to the change address. The second one is an address that I cannot understand the origin: LQKxaEyD3XLZmbXYyVna9aoJBzLxAhNS4S. I have tried to find it in the list of refund, change, receive_fund, and authorisation addresses of the Wallet and could not find it there.
Could someone explain from where is this address coming?
Kind regards, and thank you in advance,
António.

I looked into this by converting the addresses from base 58 to hex. What I got was this:
MD1AYTZnTtGKQToj2LTD7qLsSzrqcdXr9J -> 0x3237fb62589f848d3808f0b9bfe9762edabe150b93f409d315
LaPJ9TfBr6E2MSRa4t1MMhFPQAue4osUn8 -> 0x3037fb62589f848d3808f0b9bfe9762edabe150b93bab51bf3
Notice that the positions from byte 1 to byte 20 are the same: 37fb...0b93.
This is unfortunately bad news and means that the software you are using is bad.
The address that starts with M or 3 in Litecoin are pay-to-script-hash addresses (P2SH) and the software should have created P2SH outputs but it has for some reason instead created pay-to-public-key-hash outputs (P2PKH) as you can see here:
{
          "value": 15149,
          "script": "76a914a64e3a77893db78edfb3ba4abfa2106f84ba80eb88ac",
          "addresses": [
            "LaPJ9TfBr6E2MSRa4t1MMhFPQAue4osUn8"
          ],
          "script_type": "pay-to-pubkey-hash"
        },
The funds you have sent are unfortunately lost and you should stop using this software immediately since it only seems to support P2PKH addresses and not P2SH addresses.
If it is any comfort, you are not the first one to make this mistake.

Well, not a complete surprise because litecoinj does not seem to be maintained properly. Thanks Thorkil!


text:
Nonce usage in ECDSA signing algorithm
I'm trying to understand the signing function secp256k1_ecdsa_sig_sign(), and I'm curious about the nonce usage here.
static int secp256k1_ecdsa_sig_sign(const secp256k1_ecmult_gen_context *ctx, secp256k1_scalar *sigr, secp256k1_scalar *sigs, const secp256k1_scalar *seckey, const secp256k1_scalar *message, const secp256k1_scalar *nonce, int *recid) {
  unsigned char b[32];
  secp256k1_gej rp;
  secp256k1_ge r;
  secp256k1_scalar n;
  int overflow = 0;

  secp256k1_ecmult_gen(ctx, &rp, nonce);
  secp256k1_ge_set_gej(&r, &rp);
  secp256k1_fe_normalize(&r.x);
  secp256k1_fe_normalize(&r.y);
  secp256k1_fe_get_b32(b, &r.x);
  secp256k1_scalar_set_b32(sigr, b, &overflow);
  /* These two conditions should be checked before calling */
  VERIFY_CHECK(!secp256k1_scalar_is_zero(sigr));
  VERIFY_CHECK(overflow == 0);

  if (recid) {
    /* The overflow condition is cryptographically unreachable as hitting   it requires finding the discrete log
     * of some P where P.x >= order, and only 1 in about 2^127 points meet this criteria.
     */
     *recid = (overflow ? 2 : 0) | (secp256k1_fe_is_odd(&r.y) ? 1 : 0);
  }
  secp256k1_scalar_mul(&n, sigr, seckey);
  secp256k1_scalar_add(&n, &n, message);
  secp256k1_scalar_inverse(sigs, nonce);
  secp256k1_scalar_mul(sigs, sigs, &n);
  secp256k1_scalar_clear(&n);
  secp256k1_gej_clear(&rp);
  secp256k1_ge_clear(&r);

  if (secp256k1_scalar_is_zero(sigs)) {
    return 0;
  }

  if (secp256k1_scalar_is_high(sigs)) {
    secp256k1_scalar_negate(sigs, sigs);

    if (recid) {
      *recid ^= 1;
    }

  }

  return 1;
}

I'm familiar with the standard ECDSA, but what exactly is being done with the nonce here and why?
Thanks!

Can you be more specific than "what is being done with the nonce"? Do you mean how to create the nonce? Or what requirements are on it? Or something on a specific line that doesn't match your expectations?

@PieterWuille Sorry for the ambiguity, I'm new to the BTC libraries. I had assumed that the nonce was just used to generate the hash being signed, but it looks like the nonce is also used to calculate the final S value in the signature after the hash has been found. I don't recall the formal definition of EC signing addressing how to use a nonce in signing, so I suppose my question is how is the nonce used to manipulate the R,S signature values during signing? Thanks!

That's just ECDSA. The nonce is the randomness for the signature, and has nothing to do with the message being signed. An ECDSA signature is a pair (r,s) where r is the X coordinate of kG, and s = (m+r*x)/k (where k=nonce, m=message hash, x=private key, G=curve generator).

@PieterWuille Alright great that makes more sense, thanks for the quick answer.

Answered by Pieter Wuille in comments:

That's just ECDSA. The nonce is the randomness for the signature, and has nothing to do with the message being signed. An ECDSA signature is a pair (r,s) where r is the X coordinate of kG, and s = (m+r*x)/k (where k=nonce, m=message hash, x=private key, G=curve generator).

The nonce that is used in the secp256k1 function is a random private key that is generated in order to generate the final signature. To sign a message 'm' you lock that message with your private key and that generates a unique signature. The signature has two components (R,S).
The first step is calculating R using a random number (say k). This random number is generated with the help of nonce. The next step is calculating the public key using this random number using the same generator point as that of bitcoin. That means P = k*G. The x coordinate of P is then R.
Let us say that your original private key that was used to sign the signature is dA. Then the S component of the signature is:
S = (k^(-1))(hash(m) + dA*R) ----- where k is your nonce

The signature field in the bitcoin transaction has both R and S. You take this component and calculate the value of the equation
S^(-1)*hash(m)*G + S^(-1)*R*Qa ----- where Qa is the public key of your private key qA

If the x-coordinate of that equation is equal to R, then the signature is valid. So without revealing the private key you can verify the authenticity of the transaction through a digital signature from your private key. The reason nonce is used is because you need to create two unknowns so that people cannot reverse engineer the private key from the public key.
This nonce has to be random everytime you sign a transaction. If you use the same nonce, then the attacker will have two equations and only two unknowns which can be reverse engineered.


text:
Using BM1380(or other) Mining Chips
I have an old AntMiner S1 sitting in my closest, which uses the AntMiner BM1380 mining chip.
I have the data sheet for the chip, found here.
https://bitmaintech.com/files/download/BM1380_Datasheet_v1.0.pdf
there is also this repo, https://github.com/AntMiner/AntGen1, which includes reference designs of the miner, as well as firmware.
However, it is just the firmware images, not the firmware itself.
If I were to want to use a single chip(totally pointless, but I mean in some other configuration then the S1 blades) to make a small miner, how would I go about sending instructions and data to it?
Does anyone have any reference firmware source, or point me towards a document that makes sense of the required inputs?
I see on the data sheet oscillator input, oscillator output, etc. but am not sure what the required input is.
===
I am adding to the question: does anyone have an example on how to test the chip to see if it is good ? Connecting an Arduino or something like that ?

The chips don't have any firmware, or any processor at all. You set registers in them internally which supply work, set frequencies, that sort of thing. Usually people communicate with them using a small microcontroller or something larger like a raspberry pi.

Ah, maybe I worded that strangely. I'm aware the chips themselves dont have any firmware. What I'm asking about is how I actually supply the work to the chip.
If I wanted to write some code on a micro to supply a bit of work to one of these asics, what would I need to do? It's not totally clear(to me) from the data sheet.

Other chips like the Bitfury ones have frame by frame examples and documentation, if there's none for the Bitmain one you might be stuck with looking at preexisting drivers.

Excellent, thanks for the link to the bfgminer source. Do you know if bitfury sells any of their chips to consumers? Not the just announced ones, but any of their current and past lines.

They used to sell in packs and reels as bitfurystrikesback, they don't now. Their new chips are intended for consumers and developers by the sounds of things so they should be usable as well.

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


text:
How did ghash.io fall?
Years ago, GHash.io had claim of 40% of the network hashpower. They were close to 51%, where they would have the power to initiate a 51% attack. Now it has 0.2%. How did this happen?

Apparently they were hit with a massive denial of service attack in response to their growing hash rate. That combined with a subsequent drop in the price lead them to stop their cloud mining operation and focus on their exchange (cex.io).
The other non cloud-miners who left the pool most likely did it in response to the massive appeal from the community to find another pool.

I am not fully satisfied with this answer. Seems to me that only ghash.io insiders/staff can provide more info. Anyway, there are no more good answers. Take a +300 bounty!

In general, miners will quit a pool when it gets too close to 50%, because they know they could cause the network a lot of trouble if a 51% attack was ever pulled off.
Not sure of the specifics in this case, but in general that's the built-in safety mechanism.

I knew that, if we suppose that 20% of the miners quit, what happened to 30%?

Some people leave, then others decide to leave, then even more start to leave. It's a lemming train, in this case.


text:
Estimated h/s with a specific processor
I was just wondering how well this processor would do at bitcoin mining on cpuminer.

Less than 1 USD penny per year.

I should have been more specific. What do you think the hash/s would be.

10 Mhash/s, maybe.

Okay, thanks. I have an antminer R4 being shipped I was just curious.


text:
Adding «Donate» Bitcoin button in README.md file GitHub repository
1. Summary
I would like to add a «Donate» Bitcoin button on my README.md file located on my GitHub repository.

2. Not helped
2.1. Manually button
HTML-code using bitcoin protocol:

It's work on HTML page of my GitHub Pages site, demonstration.
But in .md GitHub files not one codes of Meta Stack Exchange answer not work for bitcoin protocol, demonstration.

[**![Bitcoin Donate Button**](https://www.drupal.org/files/project-images/bitcoindonate.png)](bitcoin:1DF9jgzftTFn4ZnDV2YEjUtZ3uHtBywj57?label=In%20the%20treatment%20of%20Sasha's%20teeth&amount=0.0037)

![Bitcoin Donate Button](https://www.drupal.org/files/project-images/bitcoindonate.png)

2.2. Third-party
JavaScript not supported on GitHub README.md pages. By this reason doesn't help me:

Bitcoinate
Bitcoin donate
Leo Bogert simple button

1. Demonstration

Click to donate button on page:
https://github.com/KristinitaTest/KristinitaTest.github.io/blob/master/donate/README.md
Link must be opened in your Bitcoin client, example:

2. Relevance
This answer is relevant for April 2018. In the future, the data of this answer may be obsolete.

3. Redirect
You need to use redirect.
User click on Donate button → is redirected to Bitcoin-Redirect page in current tab → then opened bitcoin wallet of user → in current tab is opened page, on which Donate button is situated.

4. Details
4.1. Source of Donate button
[![Bitcoin Donate Button](https://i.sstatic.net/MnQ6V.png)](http://KristinitaTest.github.io/donate/Bitcoin-Redirect)

If you click the image, you will go to a page http://KristinitaTest.github.io/donate/Bitcoin-Redirect. See answer on Meta Stack Exchange, how use Markdown markup for this construction. Alternative worked HTML source:

4.2. Source of Bitcoin-Redirect page

Use JavaScript methods window.location.href and history.back.

Does this method also support lightning payments?
(I am not sure whether, if one can also pay with lightning with ones Bitcoin client, and set that option as default, or whether that requires another manual step/a different client)
In essence, are the default transaction fees for a donation using this method (currently) in the range of ~$0.04 or in the range of ~$13?


text:
New to Bitcoins
I have a gaming pc (i7-6700k and R9 390) and was wondering if bitcoin mining is a good deal because they are over $600. What exactly does mega-hash mean, how many equal a bitcoin, how long does it take it take to get a bitcoin, and can I use it on amazon? I know that mining takes time from your gpu, but couldn't I just upgrade to a better gpu when I get some bitcoins? Am I missing something?

also see: I am new to Bitcoin, how can I get started?

Bitcoin mining is no longer feasible with even such high end hardware as yours. It nowadays requires special ASIC mining equipment. The performance of the connected miners is measured in Hash per Second. This means how many hashing operations of the kind required in Bitcoin is the equipment capable of doing per second. The fastest ASIC mining units currently produce a couple of Terra Hash per Second, while your graphics card will not be able to output more than a couple of Mega Hash per Second. If you have to pay for electricity, this means you will never make any profit, so go figure.
When mining bitcoins your are just randomly searching for solutions of a cryptographic puzzle, that is designed to take the whole network about 10 minutes to solve on average. There is no guarantee on how many Hashes you need to calculate, before finding a valid solution. This only counts when solo mining however. It is therefore strongly suggested, that you join a pool to make any profit. A pool distributes the work to solve the puzzle to its partakers. When pool mining, the pool can calculate your estimated income based on your share of the total hashrate of the pool.
If you want to mine with your gpu, there are 100's of Altcoins that support GPU mining and are still somewhat profitable to mine.

Thanks for the response, any Altcoins you recommend?

Shameless self-recommendation: Gridcoin. Otherwise Ethereum, Dash and Monero are solid coins for GPU mining.


text:
Is there a limit in bits for the data hashed in hash-locked script?
What is the limit in bits for the plain-text data of a secret (the data that it is actually hashed and used in a script) in a hash locked contract?

The maximum number of bytes pushable to the stack is set to 520 bytes, so that would be the maximum plain-text data of a secret (if you want to be able to redeem the output afterwards).
Another question discussing about this limit can be found here.


text:
Invalid public key was spent! How was this possible?
From previous questions this bitcoin 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh address had an invalid public key of "00" and was unspendable but the coins are now spent?? The invalid key was generated by a bug in the wallet software the owner was using and should have been "locked" due to the invalid key
see link to the owners original query
https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/
also see link to a paper that lists that this is an invalid key
https://www.microsoft.com/en-us/research/wp-content/uploads/2013/11/734.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F204914%2F734.pdf
see page 11

"00" is not a private key, so it certainly wasn't the key for that address.

@PieterWuille: It looks like the paper of Bos et al uses 00 for the "point at infinity" public key (not private key).  So there is a valid and interesting question here - either they were mistaken in their claim that it is unspendable (which might have to do with some interesting mathematical property of ECDSA), or else someone has broken ECDSA and/or RIPEMD-160 (which would be interesting for obvious reasons, though pretty unlikely).

Oh - the spending transaction is unconfirmed.  So another possibility is that it actually isn't a valid transaction, but blockchain.info mistakenly thinks that it is (perhaps because they use some homebrew validation code instead of the consensus algorithm)?

The point at infinity is not a valid public key.

@ Nate Eldredge . Oh ok, I see now it says "unconfirmed". How long does it stay in unconfirmed state before being returned or rejected?

@MShepstone It can stay unconfirmed forever. Who would reject it? We have no mechanism to agree on anything but confirmed transactions.

That address cannot be spent from and any such transaction that spends from it is invalid. However this does not prevent improperly written software from thinking its private key is a valid private and and performing the elliptic curve operations on it. So thus the address was created and a transaction was created that appears valid. But when validating the transaction with proper software, such software rejects it.
This transaction appears on blockchain.info likely because their software is either improperly implemented or simply not validating (or fully validating) transactions. This isn't the first time that's happened though.

That is correct. The address was used as an input in an unconfirmed transaction Received Time 2017-05-24 01:24:03 - it will never confirm: https://blockchain.info/tx/ba8a7fb13a507a4987bfa267a6f12defc0d30216fdf6664cdc06cc4c8de71a84


text:
Is it possible to recover coins after clicking on Reset Options button?
I use emercoin windows wallet -
Emercoin Core version v0.6.3emc (64-bit)
I clicked the button - Reset options.
The app restarted,
and balance changed to 0.
The wallet was completely out of sync after restarting.
But even after syncing all blockchain the balance doesn't change.
The balance equals 0.
My intention was just resetting options to default
but my coins have disappear.
Does it mean that I've completely lost all my coins ?
Or there is a way to restore coins ?
Need help.
I didn't create any backup wallet.

When asking a question that refers to a specific just interface, please include which application/website it is you are referring to.  Without this critical piece of information, nobody will be able to help you.

This post helps me detect a problem and fix it.

It looks like you had set a different data directory and resetting the
  options cleared that setting.


text:
Does a thin client testnet wallet exist which allows offline signing?
I appreciate I can do offline singing with bitcoin-core, but it's complex.  To make it easier, I would have to download the entire blockchain.
I have searched up electrum, but can't seem to find a testnet option.
Any ideas?

Testnet transactions have the same format as mainnet transactions, so you can just create a raw transaction on your online testnet wallet, and get it signed by Electrum with a private key it thinks is associated with a mainnet address (the version byte is different, so the same hexadecimal private key will generate a different address on the testnet and on the mainnet, but the signature will still be valid).

It looks like a testnet option was merged in early 2017, but I'm not sure if it was released:
https://github.com/spesmilo/electrum/commit/d042d6e970389f97331e9caae196bf7a3af1e293
https://github.com/spesmilo/electrum/issues/541

Electrum can be started with the --testnet option to run on testnet.


text:
Full-node bitcoin instance seems to have stopped receiving blockchain information
For some reason, it seems I am no longer receiving blockchain information from peers. When I tail the debug log file (e.g. tail -f /path/to/data/debug.log), this is what I see. Note that I have replaced the machine's internal and external IPs with w.x.y.z.

2017-03-22 01:01:45 socket send error Bad file descriptor (9)
2017-03-22 01:01:45 ProcessMessages(version, 102 bytes) FAILED peer=61
2017-03-22 01:03:13 connect() to [2001:0:34ad:4890:20d9:1be6:c114:2db8]:8333 failed: Network is unreachable (101)
2017-03-22 01:06:24 UpdateTip: new best=0000000000000000007e1cab699eba16af94e62c3c58bf8b38cc00793de83b25 height=458332 version=0x20000000 log2_work=86.161702 tx=206837725 date='2017-03-22 01:06:17' progress=1.000000 cache=218.2MiB(140090tx)
2017-03-22 01:12:45 UpdateTip: new best=0000000000000000000e7b4d72abdfbf7d0618627656ceac6ee0f81edcb51001 height=458333 version=0x20000000 log2_work=86.161736 tx=206840788 date='2017-03-22 01:12:22' progress=1.000000 cache=219.0MiB(143564tx)
2017-03-22 01:17:52 connect() to [2a00:23c4:4900:b100:6c09:9ca4:bbcc:50f7]:8333 failed: Network is unreachable (101)
2017-03-22 01:20:02 connect() to [2001:0:d5c:5a30:3828:1853:9c4b:b8f0]:8333 failed: Network is unreachable (101)
2017-03-22 01:22:25 connect() to 139.162.118.32:8333 failed after select(): Connection refused (111)
2017-03-22 01:23:13 connect() to 25.57.176.50:8333 failed after select(): Network is unreachable (101)
2017-03-22 01:23:14 connect() to [2001:0:34ac:b067:3482:d5f:a76c:d681]:8333 failed: Network is unreachable (101)
2017-03-22 01:24:47 AdvertiseLocal: advertising address w.x.y.z:8333
2017-03-22 01:25:41 ProcessMessages: advertising address w.x.y.z:8333
2017-03-22 01:25:41 receive version message: /Satoshi:0.14.0/: version 70015, blocks=458333, us=w.x.y.z:58092, peer=62
2017-03-22 01:25:41 AdvertiseLocal: advertising address w.x.y.z:8333
2017-03-22 01:27:30 connect() to 84.46.6.82:8333 failed after select(): No route to host (113)
2017-03-22 01:31:09 Pre-allocating up to position 0xd00000 in rev00810.dat
2017-03-22 01:31:09 UpdateTip: new best=0000000000000000009438446ed0a3d0a437a38a395d9893ba4b4dfa34b625e0 height=458334 version=0x20000000 log2_work=86.16177 tx=206843152 date='2017-03-22 01:30:11' progress=1.000000 cache=225.5MiB(147484tx)
2017-03-22 01:37:00 connect() to [2001:0:34af:cc99:3835:4ba:b1db:e61b]:8333 failed: Network is unreachable (101)
2017-03-22 01:40:15 connect() to [2601:681:4180:601:342e:58f4:5406:a2f1]:8333 failed: Network is unreachable (101)
2017-03-22 01:41:24 ProcessMessages: advertising address W.X.Y.Z:8333
2017-03-22 01:41:24 receive version message: /Satoshi:0.13.2/: version 70015, blocks=458334, us=W.X.Y.Z:56428, peer=63
2017-03-22 01:41:24 AdvertiseLocal: advertising address W.X.Y.Z:8333
2017-03-22 01:41:24 socket send error Bad file descriptor (9)
2017-03-22 01:44:52 Pre-allocating up to position 0x7000000 in blk00810.dat
2017-03-22 01:44:52 UpdateTip: new best=000000000000000001fcb4f772a0ccb44ae5cdcafb4af8b84546a3448db303a8 height=458335 version=0x20000000 log2_work=86.161804 tx=206845444 date='2017-03-22 01:44:02' progress=1.000000 cache=227.6MiB(151114tx)

When I type in netstat -anp | grep 8333 to see which peer nodes I'm connected to, I see the following.

tcp        0      0 0.0.0.0:8333                0.0.0.0:*                   LISTEN      16899/bitcoind
tcp        0      0 w.x.y.z:46840          212.59.241.216:8333         ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:34346          5.9.94.12:8333              ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:54488          88.99.109.181:8333          ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:51256          150.95.145.61:8333          ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:33368          52.64.15.18:8333            ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:45634          213.93.10.185:8333          ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:42636          5.189.155.84:8333           ESTABLISHED 16899/bitcoind
tcp        0      0 w.x.y.z:51966          163.172.55.147:8333         ESTABLISHED 16899/bitcoind
tcp        0      0 :::8333                     :::*                        LISTEN      16899/bitcoind

When I type in netstat -anp | grep LISTEN I see the following.

tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      2521/sendmail
tcp        0      0 w.x.y.z:28322          0.0.0.0:*                   LISTEN      16899/bitcoind
tcp        0      0 0.0.0.0:50147               0.0.0.0:*                   LISTEN      2301/rpc.statd
tcp        0      0 w.x.y.z:8332           0.0.0.0:*                   LISTEN      16899/bitcoind
tcp        0      0 0.0.0.0:8333                0.0.0.0:*                   LISTEN      16899/bitcoind
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2280/rpcbind
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      2491/sshd
tcp        0      0 :::47559                    :::*                        LISTEN      2301/rpc.statd
tcp        0      0 :::8333                     :::*                        LISTEN      16899/bitcoind
tcp        0      0 :::111                      :::*                        LISTEN      2280/rpcbind
tcp        0      0 :::22                       :::*                        LISTEN      2491/sshd
unix  2      [ ACC ]     STREAM     LISTENING     8079   1/init              @/com/ubuntu/upstart
unix  2      [ ACC ]     SEQPACKET  LISTENING     8345   1530/udevd          @/org/kernel/udev/udevd
unix  2      [ ACC ]     STREAM     LISTENING     9945   2280/rpcbind        /var/run/rpcbind.sock
unix  2      [ ACC ]     STREAM     LISTENING     10117  2332/dbus-daemon    /var/run/dbus/system_bus_socket

When I use top to look at the CPU + MEM usage, they are at 3.3% and 24.2%, respectively.
I must say that only port 22 inbound is allowed, and all other ports are blocked. This full-node is sitting in an AWS EC2 instance. But I don't think this setup is really the problem because a while back, I was getting blockchain data.
The way I start the daemon is as follows: bitcoind -datadir=/path/to/data -daemon.
My bitcoin.conf file looks like the following.

rpcpassword=somepassword
rpcbind=w.x.y.z
rpcallowip=w.x.y.z/24
rpcallowip=v.x.y.z/24
zmqpubhashtx=tcp://w.x.y.z:28322
zmqpubhashblock=tcp://w.x.y.z:28322
zmqpubrawblock=tcp://w.x.y.z:28322
zmqpubrawtx=tcp://w.x.y.z:28322
txindex=1

Here's the result for bitcoin-cli getinfo.
{
  "version": 130200,
  "protocolversion": 70015,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 458338,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 475705205061.6292,
  "testnet": false,
  "keypoololdest": 1488865612,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

A command for checking errors in the log cat /path/to/data/debug.log | grep error shows the following messages.

2017-03-20 11:37:30 socket send error Bad file descriptor (9)
2017-03-21 00:45:39 socket recv error Connection reset by peer (104)
2017-03-21 01:01:24 socket recv error Connection timed out (110)

Any idea on what's wrong?
Should I be allowing more peer connections? I've read in several places that I should NOT be connecting to more than 8 peers (the default) since I am only capturing transaction data and also increasing the peers might take away propagation resources/nodes in the global network.
Could it be the peers that I'm connected to (that they are unreliable)?
Any help is appreciated.

I'm not sure what you mean. It looks like you're getting UpdateTip messages, so you're getting new blocks. You've got 458338 blocks, which is pretty close to what you should have. Is there some command or metric that should be working but isn't?

I don't see anything abnormal in that debug.log. You're receiving new blocks just fine.

I had the same error on Ubuntu 16.04.02 running cli bitcoind full node.
Read the log eg:
tail -f ~/.bitcoin/debug.log
Where it reads this and exits bitcoind (taken from above) appeared to be due to CRC calculation error
2017-03-20 11:37:30 socket send error Bad file descriptor (9)
2017-03-21 00:45:39 socket recv error Connection reset by peer (104)
2017-03-21 01:01:24 socket recv error Connection timed out (110)
Checked memory by running memtest86 from the ubuntu installer disk or the boot menu and found the RAM to be faulty.
Replaced with new RAM and CRC/checksum values calculated correctly and problem was resolved.


text:
List of Bitcoin consensus rules?
Is there a comprehensive list of Bitcoin's core consensus rules anywhere?
In the Bitcoinwiki "Full Node" article  it says:

Here are examples of consensus rules, though there are many more:

Blocks may only create a certain number of bitcoins. (Currently 12.5    BTC per block.)
Transactions must have correct signatures for the bitcoins being spent.
Transactions/blocks must be in the correct data format.
Within a single block chain, a transaction output cannot be double-spent.

I've looked around for a list of the "many more" but haven't located one yet.

In reading bitcoinwiki "Consensus" page, I spotted this sentence: For clarity, these rules should be called hard rules or the rules of Bitcoin instead of consensus rules. This lead me to the "Protocol rules" page (https://en.bitcoin.it/wiki/Protocol_rules) which provides lists of "tx" messages and "block" messages. I'm guessing these are part of the rule set? Are there more...?

in fact the current consensus rules are defined in code of bitcoin client which is used today by majority. this is by the definition of term "consensus". tomorrow we can have another consensus rules.
the wiki page https://en.bitcoin.it/wiki/Protocol_rules is good, but it does not describe BIP16 and many other protocol improvements which were already put as consensus rules (CSV, CLTV opcodes handling, may be something else)
some things mentioned on wiki page seems to be wrong, for example the transaction can be less than 100 bytes (tx messsages, rule #6)

Thanks. I get that they're in the code, I was just wondering if they'd been transposed to a written list anywhere. I might get started on one. I also noticed a few inconsistencies on the wiki page.

"some things mentioned on wiki page seems to be wrong"
They aren't wrong, they are standard rules not consensus rules.


text:
Why A Block have a Merkle root hash?
That is the question, why a block needs to have a Merkle root hash, as Iundestand, once a block is mined the hash value of this block is stored at the header of the next one so, it generates the chain.
Is some data is changed, the hash will not be the same so, it is possible to notice that some data is changed.
So I see that storing the merkle root hash at the header of a block is unuseful as it is doing the same thing as hash pointer of the next block of the chain is doing

Every transaction has a hash associated with it. In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times — the exact process is complex), and the result is the Merkle root.
In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is a part of the block header. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the small block headers and Merkle tree – downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.
UPDATE: This feature is currently used by lightweight bitcoin clients

"Is some data is changed, the hash will not be the same so, it is
  possible to notice that some data is changed."

Yes if some data is changed then the Merkle root hash will be different.

”This feature is currently not used in Bitcoin, but it will be on the future”...? This is false, light clients use the merkle root to verify the validity of transactions. So the tech is in fact widely deployed and utilized right now.

I have investigated a bit more, and i tkink that the hash of the block is only performed over the block header, and in the block header there is the Merkle root (If a transaction is changed, merkel root value changge and as the merkle root is stored in the header, the hash of the header will change)


text:
What are the hashes in Unspent outputs?
I am a newbie to Bitcoin.
Looking at
curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK

I guess that the script is the owner's address.I am not sure about this.
"unspent_outputs":[

        {
            "tx_hash":"f2c245c38672a5d8fba5a5caa44dcef277a52e916a0603272f91286f2b052706",
            "tx_hash_big_endian":"0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
            "tx_index":47854970,
            "tx_output_n": 1,
            "script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "value": 8450000,
            "value_hex": "0080efd0",
            "confirmations":258278
        },

What do tx_hash,tx_hash_big_endian,tx_index,tx_output_n and value stand for?

tx_hash and tx_hash_big_endian are the transaction id of the transaction that this output originated from in little endian and big endian (reversed).
tx_output_n is the number of the output in the referenced transaction, i.e if a transaction has 5 outputs and you need to refer to the 5th you use a tx_output_n = 5.
tx_index I believe is an internal unique key that blockchain.info uses to identify transactions
script is the ScriptPubKey of the output, that is the conditions you need to fullfill to be able to redeem the coins.

I imagine that in building transactions we need to use tx_hash and not the big endian? I wish they would document stuff

I guess that the script is the owner's address.I am not sure about this.

According to https://en.bitcoin.it/wiki/Script

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them.

In your example

Hex
script operation
Effect

0x76
OP_DUP
Duplicates the top stack item

0xa9
OP_HASH160
Hashes top stack item with SHA-256 then with RIPEMD-160.

7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8
data
-

0x88
OP_EQUALVERIFY
Compares top two stack items

0xac
OP_CHECKSIG
Computes transaction hash and verifies signature

See Bitcoin script example
The above is a standard script which requires the spender to prove that they own the destination address of an unspent transaction output. The data in it is a hash of a public-key. Inputs prepended to the script are a signature and public key


text:
How can Bitcoin be stolen?
If each bitcoin has a ledger (Peer to Peer) and contains all the transaction history since it was mined, then how come it can be stolen?
For example, Bitcoins were stolen by hackers from Mt. Gox. If the Bitcoins each have a ledger it would show its owner and the Mt. Gox account. So it would be traceable and hard to trade if stolen.
Maybe I am not fully clear, would appreciate clarification - thanks!

Firstly, there is no "each Bitcoin". On a technical level, there is no such an object as "a Bitcoin". Rather it is a ledger of transactions, and the Bitcoin that people own are entries on that ledger.
When Bitcoin is stolen, an additional transaction is added to the ledger that says that the Bitcoin is transferred from the original owner to the thief. This transaction is exactly the same as any other Bitcoin transaction; it says money is sent from person A to person B.
In the case of a theft, the thief has gained access to the private keys necessary to send the Bitcoin elsewhere (i.e. create a valid transaction). Using those keys, the thief created such a transaction and sen the coins to himself.

Bitcoin is never technically stolen, it is the private keys used for signing transactions which are.

I believe the large threat of theft of Bitcoin or digital assets is through hacking into your account located on an exchange or possibly your wallet.  I do not believe you find theft at this point in time elsewhere.  In the future we may see qubits or quantum computing being able to conquer the blockchains security.  But as of now I believe it is through people hacking your accounts.


text:
Who set the rules for validating a block in blockchain?
Who set the rules for validating a block in blockchain?
The rules can be set the creator of the blockchain network.
There might be some rules on the application that uses the blockchain network.
Is it true?
How does the rules setting works, how does validation work.

see https://github.com/bitcoin/bitcoin

next to Andrew's reply, here is the link to the rules: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

The rules are set by the nodes on the network. The rules are coded into node software which users run. These rules are not necessarily set by the creator of the network as they can be changed if all of the users agree to change the rules by running different node software.


text:
Single API Platform for multiple cryptocurrency?
I am wondering for a single API platform where i will be able to trade for below 5 crypto currency :
1) Bitcoin
2) Litecoin
3) Ethereum
4) Dash
5) Monero
So, are you guys supporting all these in 1 packet ??
Hope your asap revert,

A lot of cryptoexchanges allow trading with currencies you're interesting with.
Here is a short list of them
1. Poloniex, https://poloniex.com/support/api/
2. Bitfinex, https://docs.bitfinex.com/docs
3. Bittrex, https://bittrex.com/home/api

Kraken deals in all of these. You can find the API at api.kraken.com

You could also consider HitBTC API.
I am also investigating this, it has 2 interfaces: REST and WebSocket, I went with WebSocket. You can get the list of symbols traded, list of all currencies, request/subscribe to ticker, candles, trades (public data). On the private side, you can create/modify/cancel orders, subscribe to notifications for orders (which gets you notifications about the trades for your order too), request the positions you have, etc.

There are many exchanges with those currencies which contain an API, or you can use pre-built API wrappers depending on your preferred language. I am including my answer from a previous post here, for API's/wrappers for crypto currency trading:

CCXT is a python/javascript library with the functionality you request. You can then trade with any exchange you'd like such as Binance, Poloniex, etc. There are commands for actions you would like to perform, such as placing an order, and you write additional code for your 'bot' to determine when to buy/sell.
Gekko is a similar open source library for Node with similar functionality for trading cryptocurrencies among varying exchanges.


text:
While attempting to fetch a particular block my node just gets disconnected by peers?
A system at an office has its testnet node stuck at a particular block.
The logs report "requesting block" over and over again for the same block and after each one reports "socket recv error" and that peer disconnects. Then it connects a new peer and the same thing happens. There are no log entries about INVALID blocks.
As a result the system hasn't had a new block in two days, but all the explorers report that the chain has continued to move advance.
The current block this node is on is a member of the best chain reported by the explorers, but thousands behind.
This node is running on Ubuntu in the US. The office network has a sonicwall firewall.

Usually when a node is stuck it is due to local corruption causing the node to incorrectly believe a block is invalid. But in those cases the logs will reflect the invalid blocks. Instead we don't see any invalidity here but the node is continually trying to get the block and getting disconnected.
This situation can be caused by overly aggressive anti-virus which is falsely detecting data in a block as malicious and cutting the connection.  Sometimes this kind of filtering is applied to the general public by nation-state level  filtering but it also shows up on office networks and in some home setups (e.g. in windows AV software).
For sonicwall you can see the disconnections in the firewalls logs and disable the filtering entirely by going into the firewall settings under sonicwall->manage->security services->gateway-antivirus and unchecking "Enable Gateway Anti-Virus", or by whitelisting the false positive match for the particular host in question.
(Thanks to Ken on IRC who had this actual issue, and for telling me how he disabled it on the sonicwall)


text:
Does Bitcoin limit the number of parallel connections from the same IP?
Is there a measure in place to prevent an adversary from connecting to a Bitcoin node many times in parallel, thus saturating its open connection slots?

The measure is that the node running bitcoin removes the cap to the number connection slots.  The cap for connection slots I have found is set to no limit when running a bitcoin service.
Sorry I stand corrected, back in 2011 looks like a cap of 125 connections was introduced Is there a connections limit on bitcoind?
in the net.cpp file  https://bitcointalk.org/index.php?topic=52772.msg629593#msg629593
but this has since been changed and I dont think there is a cap anymore... Looking at the file looks like this is the area you are interested in: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1081
and the values set here https://github.com/bitcoin/bitcoin/blob/master/src/net.h

How can removing the cap help? Can you point me to the source code?

Ok, I am aware of the 8 outgoing + 117 incoming connections limit, my question is, is there anything that prevents me from connecting to a chosen node up to 117 times from the same IP, if its connection slots are free?

I think that one node would see your 117 connections from the same ip and just block your ip on connecting.  It would seem there is no limit in the code from the discussion here https://bitcointalk.org/index.php?topic=765157.0

But it would have to be done by a firewall or some other software independent of the Bitcoin client, right?

Yeh as far as I can see there is nothing in the code to prevent the situation as u describe


text:
Bitcoin core wallet - got 0 balance after transaction
I did a test lightning transaction by sending 0.00001 btc to some exchange with using bitcoin core 0.16 (downloaded from bitcoin.org and installed to dedicated pc) and... it took the rest balance of my wallet which was sent to unknown address.
Here is the transaction: https://www.blockchain.com/btc/tx/5d6111094be588c180661cb2f0ee21a7de28a7dea8641cb9921b4aada3175dd5
As you can see there is 0.00001 btc sent to some exchange wallet and also 0.00948723 is sent to unknown address (exchange says it's not belongs to them).
What was the second transaction?

It should be change. What's the balance of your wallet before and after the transaction?

before it was like 0.0095 btc, and after it was 0

So is it possible that bitcoin.org were hacked and their wallet was compromised with ghost second transaction which stole all your rest balance when you do a tx?

Unlikely situation.

The second output is most likely change being returned to your wallet. Just like when you use a $5 banknote to buy a $1 item. You get $4 back in change. You don't try to tear off 1/5th of the $5 banknote.
Unspent Transaction outputs (UTXOs) can't be half spent, you spend the whole UTXO and get change back.

I didn't see any change back on my wallet.

Make sure you are using the latest wallet version.
Try re-indexing your block. Run your wallet with reindex option
bitcoin-qt -reindex
Its clearly a change that should return to your wallet in some time.
Here your stat -
Total Input     0.0095 BTC
Total Output    0.00949723 BTC
Fees    0.00000277 BTC

I'm using different online tracking sites to check the wallet status. So it's definitely not a local database problem.
https://www.blockchain.com/btc/tx/5d6111094be588c180661cb2f0ee21a7de28a7dea8641cb9921b4aada3175dd5
as you can see I did a transaction 0.00001 btc. BUT there is another transaction inside it which sends 0.00948723 to unknown address. And I received at endpoint only 0.00001. And the rest was disappeared to unknown.


text:
How address balance is calculated?
It does not seem practical to scan every transaction on a block chain to determine the balance for an account.  As the block chain grows this seems even more difficult and resource consuming. Perhaps all the transactions are grouped into what we used to call a record, specifically a variable length record.
address..trans1, trans2, etc...transN  for the last transaction.

Note that to bitcoin, "address" and "account" are separate things - which one are you talking about?

Bitcoin uses the so called UTXO (Unspent Transaction Output) model.
The first time it is not very intuitive because it is different from the traditional accounting model where you just spend from and send to an account.
Think about full piggy banks that can't be filled more than they are and that you have to break open before being able to spend the content:

Bob has 1 piggy bank, he wants to pay Alice with half of the piggy bank's content.
He breaks his piggy bank.
He takes half of it and gives it to Alice, who will put it all in a new piggy bank belonging to her.
You put the remaining half in a new smaller piggy bank belonging to you and which is waiting to be broken open.

Each piggy bank/UTXO is linked to an address.
A Bitcoin user can of course have several UTXOs related to his address. The sum of the UTXOs gives the amount of bitcoins owned by the address (which is one of the function of wallets).
Each transaction input is the output of a previous transaction.
Although wallet software gives the feeling that you "transfer" bitcoins or satoshis, you don't spend from an account you spend UTXO.
You spend from transactions previously made to you.

A somewhat more intuitive way to think about balance calculations is to think of you you use an actual fiat wallet.
If you want to look at how much money you physically have right now, you would open up your wallet, take out all the notes of varying denominations, and sum them up. This gives you your balance.
Bitcoin does something similar, where an address is similar to your physical wallet. A single address may have multiple utxos linked to it. The balance for that address is the sum of all the utxos.
The key thing here is that bitcoin only tracks unspent transaction outputs. Thus, to arrive at the balance for the address, it just needs to iterate through the blockchain, add new outputs when they are created, and remove old ones when they are spent. Moreover, this is a extendable process. If you know the utxo set as of block 100, you do not need to recalculate from block 0 to update with data from block 101. You can simply update your set from block 100.
This again is similar to how we use physical wallets. No one keeps track of all the notes and coins they have had in the past (spent transaction outputs). They only keep track of what they have currently (utxo). When a new transaction occurs (say you buy milk), you only update the current state of your wallet by removing a note, and putting the change back. You don't need to calculate it from the first time you used money.
Bitcoin takes this a step further and has a concept of accounts, which are multiple addresses that act as one wallet. A similar analogy would be if everyone in your house pooled the money from all of their wallets, so that you can spend it as one. Again, the balance of an account is simply the sum of the balance of the addresses in it.

Edit:
Address Balance Calculation
An address balance is calculated by adding up all of the values of the unspent transaction outputs (UTXOs) that are spendable by the key pair corresponding to that address.
Storage Structure
To answer the broader question: "why do you scan every transaction on the entire blockchain to determine your balance?"
Bitcoin core does not need to know the balance of an address in order to do validation. It does, however need to be able to scan through all previous transaction outputs in order to validate new ones. To do this, it scans a generated indexed database (by txid) of all transactions for the previous outputs referenced by a new transaction, and verifies that the signature satisfies the previous output (UTXO). Note this only requires scanning unspent outputs not all transactions.
Optimizing this data storage for balance calculation by indexing by address and txid might make balance calculation easier, but it isn't necessary for validation and would be at the expense of transaction verification efficiency. It is better to leave this to a wallet application for the sake of the network.
Previous Answer:
The previous answer explains how to index transactions in bitcoin core which can help a wallet or block explorer determine an address balance more efficiently.
You can index the transactions on the blockchain to make it more easily searchable. Bitcoin-core allows this using the -txindex=1 flag.
From the Bitcoin Wiki:
txindex | Maintain a full transaction index, used by the getrawtransaction rpc call (default: 0)

This has nothing to do with address balances.

I agree, the title doesn't seem to match the question. The question talks more about the practicality of scanning all transactions and how that could be done.

And the answer has no relation to that, because the txindex isn't used for validation even.

Yeah that makes sense, the question is more high level

Just updated the answer to better address the question.

There is no index of txids (or index whatsoever) used at any point in time during validation.

Is this answer referring to a different utxo index, then? https://bitcoin.stackexchange.com/a/29782/60443

Bitcoin Core maintains a database of all unspent transaction outputs. It isn't an index, as it doesn't index into anything else. The original transactions or blocks that created the outputs being spent are not accessed. It's just adding new outputs to the database, and removing the ones that are spent.


text:
Raw transactions - SubtractFeeFromAmount flag
I'm currently working on a project (I'm a beginner in the world of cryptocurrencies) where we are using Raw Transactions, I want to know if in raw transactions there's a flag similar to subtractFeeFromAmount flag that exists in the sendToAddress method.

When you create a raw transaction, you must specify all inputs and outputs, and any leftover will go towards the fee (to the miner). The raw transaction does not do any fee calculation.
Example Transaction:
input1: .1BTC
input2: .2BTC

output1: .299BTC

The resulting fee would be:
fee: .001BTC

This amount gets added to the coinbase transaction (by the miner) of the block which includes this transaction.


text:
bitcoin address from xpub key
I want to create bitcoin address from extended public key, without exposing private key but did not get any success till now. Do someone know how to do it? I am using bitcore-lib package

can you provide any code and the problems you're having?

According to BIP32 you're trying to generate a non-hardened child address, see BIP32 - Public parent key → public child key.
Using bitcore-lib, to derive a non-hardened child public key and a P2PKH address:
var bitcore = require('bitcore-lib');
var Address = bitcore.Address;
var PublicKey = bitcore.PublicKey;
var Networks = bitcore.Networks;

var hdPublickey = new bitcore.HDPublicKey('tpubD6NzVbkrYhZ4XLMmry7XriYJ6Xgx1vQqoUZHLUXQPDB32n7pQYaWSMpRttm2sHzYjsQqrsAZYyJCmoEJB51oSdqZxq7epGjP4vHriCYz7Tp');
var orderPublickey = hdPublickey.deriveChild("m/44/145/0/0");
var pubkey = new PublicKey(orderPublickey.publicKey);
var address = Address.fromPublicKey(pubkey, Networks.testnet);
console.log("address", address);

Returns:
address <Address: mkVBk6gZ7rBLYXvpdcKwTEq6SjHvSeLwZ8, type: pubkeyhash, network: testnet>

could we convert  this publicKey into bitcoin base58 address?

I got this method bitcore.Address.fromPublicKey() but it is not working

What is it doing? Also, try var address = Address(publicKey, 'mainnet').toString(); Also it depends on what type of address you want (p2sh or p2pkh)

please define Address? do you have any working code that can generate bitcoin address from xpub?

Have you tried the above? Is it not working for you?

i have tried lots of time in addr = Address(publicKey, 'mainnet').toString(), i am trying to figure out how to define Address??

see my edit above.

Let us continue this discussion in chat.

hii @JBaczuk i inboxed you

How can i get the privatekey for the above adddress mkVBk6gZ7rBLYXvpdcKwTEq6SjHvSeLwZ8

@IshwarChandra you can't. If you could, then how would you ever hold Bitcoin without someone computing your private key and stealing your funds?

@JBaczuk yeah i know .you are right.....

@JBaczuk today i exported xpub from coinomi and used in the above code to generate bitcoin address and sent bitcoin.... now my problem is how can i get the fund i sent to that new bitcoin address, which is not in my coinomi wallet and even i did not get any notification incoming transaction on my coinomi wallet

@IshwarChandra doing that is most likely is not supported by their application. Hopefully you can export your private key from coinomi, then you'll have to figure out how to sign a transaction with that key and send it back to an address in one of your wallet applications.

@JBaczuk thanks, my requirement is if someone sharing me his xpub from exodus or any xpub supported wallet and i am creating bitcoin address using that xpub so is there any way like he can manage those funds. I mean, I will only generate the addresses using xpub and the one who is having xpub, xpriv and its mnemonic he can access/use that funds.

@IshwarChandra There are ways, but I don't know if there are any wallets that would support what you want out of the box. You might have to create your own.


text:
How do I know that a node provides the accurate blockchain
When I connect with a wallet to the bitcoin network, how is the balance actually retrieved? One node? Or more? I understand it is a sum of all transactions. But when I load my wallet I assume I connect to certain node. How do I know that that particular (malicious) node has the most recent or valid blockchain? In other words: can it be possible for a node to cheat by adjusting the blockchain which I could connect to with a wallet and get a faulty balance?
I read some articles about this and they state that this will be rejected by the network. But I have no idea how this works. Can somebody help?

Edit: this answer is written assuming you are asking about ‘SPV’ or ‘light wallet’ implementations, not a full node implementation

How do I know that that particular (malicious) node has the most recent or valid blockchain?

This is two separate questions: are you up to date? And is the info valid?
Up to date: it is possible for light wallets to query data from multiple network peers, though not every implementation will do so. This helps ensure no single node is ‘lying by omission’, which means they are withholding information from you (Interesting related info: ‘fraud proofs’ are apparently very, very difficult to craft. It is an ongoing area of research in the field). If you are only connected to malicious nodes, this may become an issue, though in practice it is not a difficult issue to overcome (see: Sybil attacks / eclipse attacks).
Some light wallets will connect to a server run by the developers of that wallet, while others will connect directly to a node(s) in the bitcoin network. Using a service that does not hardcode their own server into the wallet is probably better, though if they follow a standard HD wallet scheme it should be no problem importing your seed phrase to a different wallet in case that service goes down.
I think the best advice is to run your own node. Many light wallets allow you to point your wallet at your own node as a manual setup option. This gives you sovereignty, and greatly increased privacy as well.
Validity: light wallets work by downloading the chain of block headers, and then requesting info related to the wallet’s address’ from connected nodes. By only downloading the blockheaders, resource usage stays low enough for the wallet to work on mobile (less than 100mb for the entire bitcoin history, currently).
The header contains the transaction merkle root, which can be used to locally verify that a valid transaction is included in a certain block, without having all of that block’s data. A node will serve the transaction in question to the wallet, along with the intermediate hashes in the merkle tree. This allows the node to recalculate the merkle root locally, giving proof that the transaction is confirmed on the bitcoin network (and thus valid according to the network’s rules). If even one bit of information is changed, the merkle root will be calculated differently, and the wallet will know the transaction served is invalid.

This is a good question. Your best bet is two-fold:

Connect to known peers. These are hard coded as DNS seeds in the full-node application. See chainparams.cpp #L132
Connect to many peers to get as much of a view into the network as possible.

If you don't do these 2 things it's possible you get connected to an invalid side-chain rather than the more popularly accepted chain, though not very likely.

When you first load up the bitcoin client you are searching for the network of peers that you can download the blockchain from, starting from block 1.
So you could connect to a malicious node but the malicious node will have altered the latest blocks only.  There are hardcoded checkpoints in the blockchain history written into the code, so altering the history and getting all the other nodes of the bitcoin network to agree with your blockchain can only be done with > 51% of the mining power and some other funky stuff.
Your coins in your wallet will not be spendable until the blockchain has fully caught up, it is reading the local transactions into and out of the wallet that it knows about and as the blockchain is downloaded it learns more of any recent transactions not made from that wallet.dat file of addresses.
The malicious node as you say is rejected by the network for not having agreement of blocks and transactions and they can only not be orphaned on their own chain if they have the 51% or more hashing power.


text:
OpenSSL bitcoin addresses generation
Using OpenSSL ver 1.1.0h on win 8.1 - 32 bit
Im trying to recreate this post using cmd: OpenSSL generate Bitcoin address
But on step 3:
openssl ec -in c:\keys\private.pem -outform DER|tail -c +8|head -c 32|xxd -p -c 32 > c:\keys\private.key

I got this error: ec: Unknown cipher c
Any idea what im doing going wrong?

Try putting c:\keys\private.pem in quotes, like "c:\keys\private.pem"

I got the samme error :(

I don't have a windows machine on hand, but it's probably just a location issue. Try moving private.pem to the same directory you're running the command from, and using a relative path

If it is a locations issue, why steps 1&2 works ok?

I did the same exercise on my OSX system, and this is my result:
$ openssl version
OpenSSL 1.0.2j  26 Sep 2016

$ openssl ec -in privkey.pem -outform DER|tail -c +8|head -c 32|xxd -p -c 32
read EC key
writing EC key
18e14a7b6a307f426a94f8114701e7c8e774e7f9a47e2c2035db29a206321725

I assume that the PEM key is not in correct format, PEM follows some specific rules. There are several discussions also here in bitcoin.SE
My privkey.pem looks like this:
$ cat privkey.pem
-----BEGIN EC PRIVATE KEY-----
MFQCAQEEIBjhSntqMH9CapT4EUcB58jndOf5pH4sIDXbKaIGMhcloAcGBSuBBAAK
oSQDIgACUIY61kqHroov6Dwa8ahAPLU/U+SG2FEdrYoEiH5bI1I=
-----END EC PRIVATE KEY-----

This is a "test" key, note the word "Risc" in the generated bitcoin address from this key. Don't use it for any value, the funds will get lost.
If you have a test key, and really it is a test key, you can share it, and we can have a look at it (and you will then never ever use it again).

I guess is more something about OpenSSL version. Even in the same thread i mention as source, other user comments that with 1.0.2 it is working too. Looks like it is a little bug


text:
Bitcoin Transaction using API with Custom Fees
I want to transfer Bitcoin from one individual address to another using API. But I want to set Transaction fees as per my requirement. So How can I do it ?
Right now I am using blockchain-transaction - npm api for transfer bitcoin from one address to another. So please shade some lights on this.
var bitcoinTransaction = require('bitcoin-transaction');
//Send all my money from wallet1 to wallet2 on the bitcoin testnet
var from = "mm3gdVh8n6YtcNyaTKYkveB6yTME7aDWNJ";
var to = "mgPUfqJk4X6gE4P5Do5RfpkTFsYmsSjCya";
var privKeyWIF = "cNZi8iySqBToXMpcsQaHKD5uv7HExBQJBSi4dTg3ZPaEzeNAzvbj";    //Private key in WIF form (Can generate this from bitcoinlib-js)
bitcoinTransaction.getBalance(from, { network: "testnet" }).then((balanceInBTC) => {
    return bitcoinTransaction.sendTransaction({
from: from,
to: to,
privKeyWIF: privKeyWIF,
btc: balanceInBTC,
network: "testnet"
});
});

I have not tried this myself but having a look through the documentation on blockchain-transaction - npm api it looks like you can query fees, under the advanced section:

fees - Gets a list of current fees based on the BitCoin network going
  rate.

https://www.npmjs.com/package/bitcoin-transaction
Looks like you can select a 'fastest' option or others:

Set the fee for the transaction. Can be either one of "fastest",
  "halfHour" or "hour" in which case the actual fee numbers are fetched
  from the fees provider. Or it can be just a plain number in which case
  that will be used as the Fee per Byte value in Satoshis. It is
  recommended to use one of the string aliases unless you know what you
  are doing.

You might have to specify a feesProvider, not sure if they have a default selected when nothing set.

I have try it in my code but it's not working. It shows me same error.
First of all I try Fees=3(as integer) after that Fees="3"(as string) and also I have try for FeesProvider. but no luck.

"It is recommended to use one of the string aliases unless you know what you are doing."

"Can be either one of "fastest", "halfHour" or "hour" in which case the actual fee numbers are fetched from the fees provider."

Finally I get answer for this question by surfing very much for this topic.
I found source code for transfer Bitcoin from one individual account to another.
"https://github.com/Blank101/bitcoin-transaction/blob/master/index.js"
and there I set feePerByte = 3 as per my requirement. So by set this Transaction fees My transaction does not deduct much more fees.


text:
Synchronisation stopped at one specific blockchain
I've successfully been using Bitcoin core for the past months, but since two weeks ago its synchronisation is always stopped at the exact same blockchain.
2 weeks later, sync is behind by 2 weeks. And the error message is still the same: "No block source available" and I have 0 active connections to Bitcoin network.
I have updated the client, and changed networks (I even tried from another country to tell you the truth).
I tried to type in "rescan" and "reindex".
EDIT : they worked, but sync is now stopped at another block...
Here is the end of the debug window after I did a rescan :

2016-12-25 21:36:12 Still rescanning. At block 440686. Progress=0.988020
2016-12-25 21:36:53  rescan               821342ms
2016-12-25 21:36:54 mapBlockIndex.size() = 441449
2016-12-25 21:36:54 nBestHeight = 441448
2016-12-25 21:36:54 setKeyPool.size() = 100
2016-12-25 21:36:54 mapWallet.size() = 6
2016-12-25 21:36:54 mapAddressBook.size() = 10
2016-12-25 21:36:54 init message: Chargement des adresses...
2016-12-25 21:36:54 torcontrol thread start
2016-12-25 21:36:54 Loaded 60362 addresses from peers.dat  457ms
2016-12-25 21:36:54 init message: Chargement de la liste d'interdiction...
2016-12-25 21:36:54 init message: Starting network threads...
2016-12-25 21:36:54 AddLocal([2a01:cb00:b1d:1d00:7f:42c7:afca:6f9a]:8333,1)
2016-12-25 21:36:54 Discover: ASUS-PC - 2a01:cb00:b1d:1d00:7f:42c7:afca:6f9a
2016-12-25 21:36:54 AddLocal([2a01:cb00:b1d:1d00:d8e0:fea5:2db:481f]:8333,1)
2016-12-25 21:36:54 Discover: ASUS-PC - 2a01:cb00:b1d:1d00:d8e0:fea5:2db:481f
2016-12-25 21:36:54 dnsseed thread start
2016-12-25 21:36:54 net thread start
2016-12-25 21:36:54 addcon thread start
2016-12-25 21:36:54 opencon thread start
2016-12-25 21:36:54 msghand thread start
2016-12-25 21:36:54 init message: Chargement terminé
2016-12-25 21:36:54 GUI: Platform customization: "windows"
2016-12-25 21:36:54 GUI: PaymentServer::LoadRootCAs: Loaded  44  root
  certificates
2016-12-25 21:37:05 Loading addresses from DNS seeds (could take a while)
2016-12-25 21:37:05 0 addresses found from DNS seeds
2016-12-25 21:37:05 dnsseed thread exit

Any leads ?

-rescan and -reindex are startup parameters. You add them to the startup command of Bitcoin Core, I don't think you can use them from the console.

Possible duplicate of What can I do when the blockchain synchronization is stuck at a specific block?

Possible duplicate of How to resolve “no block source available”?

OK I'm sorry I'm going to need to ask you how to do "add them to the startup command" exactly... Thanks.

See this description, you'll have to replace -zapwallettxes with -reindex.

Hello,
Thanks for the help, but the -reindex command did not work. After a few days of running (reindex is slow...) the sync is now stopped 3 blocs after the one that it stopped before...
Any hints ?

Does the debug.log say anything else besides the previous error message?

I added the end of the debug.log in my opening message. Thanks so much for your help. I have 300$ that will be lost if I don't manage to make thi work again...

Murch any insight ? Please I'm starting to lose any hope...

Is this a recent or old version of Bitcoin Core? What hardware are you running this on? Is it possible that your CPU is overheating? It is possible that either your disk or your computer is making mistakes in the calculation, and then a valid block comes out as invalid and the remainder of the blockchain thus cannot be synchronized. If you just want to get your money out see Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately?

Have you tried manually connecting to a specific node (e.g. found on bitcoin nodes)?

I've just tried asking around for more suggestions: Are you using a VPN or Tor?

Thank you for your help !
I am using Bitcoin Core v0.13.1. I am running this on my laptop (windows 7 flash disk), and my CPU is not overheating. I don't think hardware could be the issue here.
I will use your link to access my bitcoins, I will give up on repairing Bitcoin...
Best regards !


text:
What are the minimal system requirements to run a full Bitcoin node?
I want to build a low profile system running as a full Bitcoin node, i.e. just running Bitcoin Core 0.9+ and pretty much nothing else. What is the minimal system (in terms of power consumption) that would be suitable for this task? Just bitcoind will do, no interface or visual interaction needed.
I'd really prefer something where I don't need to build all the software manually.
A simple small netbook would do, I guess. But could I even use something like a Raspberry Pi? Or perhaps some other single board computer?
I assume it'll need at least 20-30 GB disk space (for OS + Bitcoin Core with entire blockchain). Is there a minimum amount of RAM I'd need for bitcoind?
Curious to hear what kind of system and OS you guys would recommend for this!
(P.S. to avoid confusion: I just mean running a full Bitcoin node, not mining)

You can run a Raspberry Pi with bitcoind no problem. I have several Pi's running bitcoind in various locations and some of them have over 100 connections. Use a 64GB flash card and make sure you have a 512MB swap file. The only limitation you will find is your broadband upload speed , the Pi or it's flashcard will not be the bottlekneck. Use a good quality flash card like Sandisk etc. Also tell your router to route incoming connections on port 8333 to your Pi's IP address. The reason the only limitation is your broadband upload speed is because of parasitic loads such as new users trying to upload the entire blockchain from your Pi. If you do this , try to set your Pi up with blockcahin already loaded onto flash or SSD otherwise it will take some time to synchronise.

The swap partition needs to be emphasized. Mine uses 900MB~ swap.


text:
Recommendation for educational mining
I've been running a full bitcoind node (Ubuntu) for a while now and would like to experiment with mining for educational purposes.
Googling anything to do with "Bitcoin mining" is fraught so I was hoping some more informed user can sanity check my plans.
I was going to buy a 20-40 G/H USB ASIC, plug that into the node and run BFGMiner on the same system, using its solo-mining configuration to communicate with my bitcoind RPC service.
Is this a good way to proceed? If not, any other recommendation would be appreciated.

Hi Garreth, your question might be covered by https://bitcoin.stackexchange.com/q/41276/5406, check it out!

It doesn't. My interest is educational.

Well what do you want to learn about? There are many aspects to mining; the protocols used, the hardware available, infrastructure and maintenance, latency aspects, economics of it all, ... how to learn about those will depend on what you're interested in.

I basically just want to know that buying something like a Gekkoscience USB miner and running it with something like BFGMiner of GGMiner will work. These are essentially legacy technologies at this point, and I don't want to waste $70.


text:
How to distribute UTXOs in hard fork while preserving privacy?
Let us say I have a UTXO set S = {U1,U2, U3 ..., Uk} on a pre-fork bitcoin blockchain.
How do I spend the previous UTXO S so that the new UTXO sets on both the chains are not linkable/tracable? Are there any common practices which people use for it? What are the trade-offs of different approaches?

Create a new UTXO set, do you mean spending your outputs?

Yes, I mean spending the outputs on both forks. I edited the question for more clarity

At the point of the fork, both chains are identical, and thus all UTXOs are identical. All spends of those outputs are completely public as always, in the blockchain. So your question really comes down to whether you can hide which UTXOs you are spending in a given transaction, with or without the fork. The only way I know how to do that is via mixing. If you send your transactions in each chain to a mixing service, you'll end up with different outputs on each chain. The untraceability of the mixing is then dependent on things like how many other transactions are being mixed at the same time (on a new fork, there may be fewer people sending coins), or whether the value of the output you're spending is identifiable coming in and out of the mixing.

I should have elaborated the question more. Let us say I want to sell my 1 fork, BCH for example. One naive way would be to create a transaction which has inputs the entire utxo set and only 1 output on BCH. By doing this, I have effectively told the world that all the utxos on Bitcoin blockchain (which I am yet to spend) belong to 1 person. On the other hand, if I spend each utxo to create only 1 output on BCH, there is not much privacy loss, but takes up much effort


text:
How to verify Wrapped Bitcoin (WBTC) issuance
I'm trying to understand how Wrapped Bitcoin (WBTC) issuance can be verified.
The WBTC custodian, BitGo, published the following material:
https://wbtc.network/dashboard/audit
This is a list of Bitcoin addresses linked to Blockstream explorer where you can verify the UTXOs each address has access to (wallet balances, if you will). The sum total of these balances is equal to the amount of WBTC minted by BitGo.
However, how do I know that BitGo has the private keys for those UTXOs? Am I supposed to just accept the bonafides of BitGo and their audits, or is the a technical way to remove that trust?


text:
Technical problems in deployment of segwit parallely on bit 4
Recently(as of May 24, 2017) segwit2mb HF has been proposed. A core developer has reported that another deployment of segwit via bip 109  on bit 4 would require code duplication.
Although the above link comes with some justification, I fail to understand the reasoning.
What will be consequences if we simply change the block threshold(95% of 2016) to 80% of 2016 and give it out as a new binary? Is there a network split risk?

If the miners activate segwit by signaling readiness for segwit on bit 4 (further called segwit4) immediately, all nodes that follow the current activation procedure (signaling on bit 1) would ignore this activation. Regular segwit enabled nodes would interpret transactions and blocks created with segwit according to the old rules. After segwit4 activated they would still consider segwit transactions to be not allowed yet, and thus with the first segwit4 transaction appearing on the network, ban the relaying nodes for forwarding invalid transactions. At this point, this would split the network between miners and all nodes that are segwit1-enabled.
Activating two different versions of segwit on the network would trigger untested interactions between nodes, as several parts of the relay code logic is dependend on the signaling bit. Only interactions between segwit-enabled and segwit-unaware nodes were tested extensively, so one should expect new code and new test cases to be necessary to avoid a netsplit with segwit1-enabled nodes.
This would perhaps not matter terribly much, since according to Garzik on Twitter the blocksize increase would be activated at the same time as SegWit4, so any old type nodes would be hard forked off the network anyway as blocks created by the new chain would appear invalid to them.
Update: Apparently, there are at least three opinions out there about the activation order of segwit, and the hardfork since Consensus, so I'm waiting what it'll be.

As far I understand the argument by G Maxwell concentrates on code path duplication and avoiding combinatorial testing. Most of the current segwit code in 0.13.1+ is already active and is been used even for not segwit code, so there is very little chance of a dead code turning up after segwit activation.
So for segwit4 we have three options:

As you suggested, completely drop support for segwit1 and just search, replace bit1 by bit4 and 95% by 80%. The problem with this is that if later segwit1 catches suppport, we are hardforked out of the network and then we have to downgrade our node to avoid forking out. Note that this is probable since majority of network is already on segwit1 support. A fact which is also used by BIP148 to force segwit activation.
Retain support for segwit1 and add segwit4. With this we are not forked out, but has issues with code duplication and testing.
Wait for segwit1 to expire and then do search/replace. This is safer option suggested to avoid problems with 1. and 2.

Can you elaborate(with respect to Option 1) as to why would the network HF after segwit1 activates? What transactions would be invalid in 1 network while valid in other one?

Blocks having segwit transactions willl be rejected by our node. This will work how it is working right now, the code is the same and we haven't reached segwit activation. Other majority nodes on segwit1 will accept segwit blocks

Concerning option one, the agreement suggested that SegWit would immediately be rolled out with bit 4. However, first the code would need to be written. You liken this to a search&replace, however also the code for the hard fork needs to be integrated as that is supposed to be locked in as well. Second, the miners would need to upgrade to the code. But finally, also a sufficient amount of nodes would have to update to the code, as otherwise the network would split and before a majority enforces segwit4, it would be unsafe to use.

Concerning option two, it would probably be the easiest to go with BIP91. But even then, to adhere to the Silbert agreement, hardfork code would need to be integrated with segwit first. Option three would push capacity increases back another six months at least. However, fees are already going the roof today.


text:
How to compute double sha256 shown in examples of bip 143?
How do I compute the double sha256 shown in example of bip 143?
The example in Native P2WPKH
  hashPrevouts:
     dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
     = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37

I tried
  export PREV_OUT=fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000
  echo -n $PREV_OUT |openssl dgst -sha256 -binary |openssl dgst -sha256

This is what I am getting
  cf4cff3b2196ae87636af6088736f0f9102106375f306c032804845a2d3b92d4

Do this:
echo -n $PREV_OUT | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -sha256

Explanation
You want to do this:

prevout (raw bytes) -> sha256 -> sha256 -> convert to hex

You're doing this:

prevout (raw bytes) -> convert to hex -> sha256 -> sha256 -> convert to hex

xxd -r -p reverses the hex conversion.


text:
Bitcoin Core - When is fAllowWitness evaluated to true?
In Bitcoin Core, when is fAllowWitness evaluated to true?
transaction.h
const bool fAllowWitness = !(s.GetVersion() & SERIALIZE_TRANSACTION_NO_WITNESS);

In particular, I cant figure out the value of s.GetVersion()
Thank you

Doing a grep on SERIALIZE_TRANSACTION_NO_WITNESS shows that it's ORed with PROTOCOL_VERSION when creating a CDataStream object for example. This is the first clue that the no witness flag is to be found along with the version protocol.
A little more digging shows that this define is used when building a Tx message in lines 1105-1126 of net_processing.cpp (v0.15.0.1):
        else if (inv.type == MSG_TX || inv.type == MSG_WITNESS_TX)
        {
            // Send stream from relay memory
            bool push = false;
            auto mi = mapRelay.find(inv.hash);
            int nSendFlags = (inv.type == MSG_TX ? SERIALIZE_TRANSACTION_NO_WITNESS : 0);
            if (mi != mapRelay.end()) {
                connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *mi->second));
                push = true;
            } else if (pfrom->timeLastMempoolReq) {
                auto txinfo = mempool.info(inv.hash);
                // To protect privacy, do not answer getdata using the mempool when
                // that TX couldn't have been INVed in reply to a MEMPOOL request.
                if (txinfo.tx && txinfo.nTime <= pfrom->timeLastMempoolReq) {
                    connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));
                    push = true;
                }
            }
            if (!push) {
                vNotFound.push_back(inv);
            }
        }

The above code shows that the int variable nSendFlags may contain the no witness flag. Later, msgMaker.Make will use this variable to create the Tx message as shown in line  1119:
                    connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));

You can then follow the serialization by looking at the class CNetMsgMaker in netmessagemaker.h which itself uses CVectorWriter to serialize the data.
To summarize, the GetVersion() value is built using the protocol version optionally ORed with the SERIALIZE_TRANSACTION_NO_WITNESS. This value is never sent over the wire. It's used only to control the serialization of the Tx message.


text:
Does my bitcoin multiply with every fork?
Simply put, does your current bitcoin (pre-fork) multiply with every fork that bitcoin may experience?
For example if I have one bitcoin stored in a cold wallet for the next century and Bitcoin experiences 5 forks over that period. Will I have the original bitcoin and 4 new coins (differently named)? Assuming every new coin type is still going.
Also, if you have 1 bitcoin in a hot wallet or exchange, does the exchange then issue you with the new coin with every fork? What if your exchange does not support the new coin?
Sorry, lastly... Say your bitcoin is in cold storage. At what point do you see the new coin? Will an exchange automatically recognize it as a pre-fork bitcoin and issue you the new coin?

Note that the word "fork" can have several meanings. The more common one is a protocol change (either a soft or hard fork) where everyone switches to the new protocol. In this case there will still be only one type of coin.
You are talking specifically about a scenario where both the new and old versions are being used. In this case the network and the currency will split into two separate networks, blockchains and currencies. I will refer to such a scenario as a "split".
In essence, if the split is done properly, then the two networks will be incompatible and not recognize each other. Each will believe it is the one true coin, and will treat any transaction on the other network as invalid garbage.
The two networks do share a common blockchain history up to the point where the split happened. So if you have a bitcoin in address X in cold storage prior to the split, each network will recognize that there is a bitcoin in address X, so you will indeed have a coin of type A and a coin of type B. If there are several splits while the coin remains in the same address, you will have a coin in each of the resulting currencies.
You can "see the new coin" the moment there are block explorers for both networks. You can examine the block explorer for network A and see that you have a bitcoin, and you can examine the block explorer for network B and see that you have a bitcoin. Once you've installed wallet software for both network types, you can import your private key to both and have each display that you have 1 bitcoin.
This means that you are now able to create two transactions - one that sends a bitcoin to an address C of your choosing, which will be recognized as valid by network A; and one that sends a bitcoin to an address D of your choosing, which will be recognized as valid by network B. (This requires that there will actually be software available for both networks A and B, and that it will be careful not to create transactions that might be mistakenly picked up by the wrong network).
What happens next involves interaction with the real world, and the real world is messy. There's no absolute answer to what will happen as it depends on what kind of software and services you are using.
If you "have 1 bitcoin in an exchange", remember that you do not really have a bitcoin, the exchange has a bitcoin and is contractually obligated to give you 1 bitcoin when you demand it. This becomes messy when a split happens and it's not universally agreed what "bitcoin" means.
The exchange will, technically, definitely now have both a bitcoin A and a bitcoin B. What will it do about its contractual obligation is up to it. The exchange could treat both coins as legitimate, support balances of both Bitcoin A and Bitcoin B (the same way it has balances of any other currency), and credit you with 1 bitcoin in both (since your pre-split bitcoin really is equivalent to a bitcoin on both). Then you can either withdraw both, sell both or any other combination.
Or it could decide that only one of the coin types is legitimate. So it will run only nodes of Bitcoin A, recognize only transactions of Bitcoin A, and list a balance only for Bitcoin A (which it will just call "Bitcoin"). When you ask to withdraw your bitcoin, it will send you only a bitcoin A. It is technically capable of sending a bitcoin B as well but it ignores this possibility. The bitcoin B will probably be lost (or at least kept by the exchange).
So, it's in your best interest to keep your coins only in exchanges / hosted wallets that recognize the importance of handling splits properly. (Or, preferably, not keeping your coins in exchanges or hosted wallets at all).
I've analyzed the contingency of a split in more depth at https://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/.

Thanks for both answers. I have edited the question with another scenario...

@Josh: Ok, I've expanded my answer accordingly.

So just to be absolutely clear: if on july 22 you had 1 bitcoin rated at $2810, and on july 23 the BTC/BCH fork happened, then on july 23 you owned both 1 BCT opening at $2808 and 1 BCH opening at $555 , with the possibility to sell the BCH for $555 and buy more BCT with it, giving you instant 20% more BCT?! Is it really that simple to understand!? Or am I missing something?!

@nl-x: One thing you may be missing is that when there is a significant split, many exchanges halt trading until the dust settles. Otherwise they cannot sync balances with blocks. When trading resumes, there is no reason BTC should trade for the same price it did before - prudent traders will update the prices offered, taking into account that the "Bitcoin" they are now paying for does not award BCH as well, and thus less valuable than the pre-split BTC which also awards BCH. So if the market estimate post-split BTC to be worth $2300 and BCH to be $500, it will valuate pre-split BTC at $2800.

@MeniRosenfeld I used actual figures in my example that I got from here https://coinmarketcap.com/currencies/bitcoin/historical-data/?start=20130428&end=20171120 and here https://coinmarketcap.com/currencies/bitcoin-cash/historical-data/?start=20130428&end=20171120 . Before was $2810, and after was $2808 +$500. It shows BCH listing starting July 23, so I assume that was the fork date (?)

@nl-x: Well, not, the fork date was on Aug 1st. Before that date the only thing that was trading was BCH futures, which obviously were very low volume and not indicative. The actual BCH price after the split was lower. Anyway, the market isn't 100% efficient, and in any case prices are very volatile.

Yes, that's basically how it works.  You will still only ever own one bitcoin, since only one branch will ever be considered to be "Bitcoin".  However, you will also own 4 other coins on 4 other blockchains.  You should also be aware that if any of these 4 coins have significant value, it is likely because Bitcoin has decreased in value.  In other words, the value of the forked coins only have value that they took away from the one still called Bitcoin.