It depends on what PoS system is considered (or not, since I think the answer is the same either way).

Cunicula's system is completely different from what we have now. There's no way to "half" switch to it since a block which is valid in the current system means nothing in his system, and vice versa.

My system uses a skeleton which resembles the current system, so in theory you could solicit signatures in parallel and let anyone use them or not as he pleases. As theymos says a fork will still occur once there's a disagreement between the two systems about which is valid; and anyway, I think the process of collecting signatures and embedding them in the blockchain requires enough rethinking of the network that it is meaningless to regard it as anything but a hard fork.

Of course, even if you make an entirely new alt for it, you can always provide a built-in mechanism to allow bitcoin owners to import or copy their wealth, to make sure the early adopters of decentralized digital currencies at large don't suffer from the advent of a new and potentially better alternative to the original Bitcoin.


I have a 2012 Macbook Pro mining Litecoins (CPU&GPU at a combined 80kHash/s) and a 2011 iMac (71MHash/s on its HD5670) mining BTC. They both run overnight and on weekends, I turn the mining software off over the weekday. Doing this for months now.

So far, there were no overheating problems, but i have an extra cooling stand for the Macbook, which i would recommend.

Still, I expect the hardware to die sooner. The heat management in Apple machines is very delicate because of the case design, and I heard of people waking up to a dead iMac.


How many unit test should be run after building a node?

There is one unit test binary which contains several hundred tests within it. make check just runs the binary, and if none of the tests within it fail, then make check passes. Because there is only one binary, make check sees this as being only one unit test, but in reality, all 200+ tests are just packaged into the same binary.


What are QR codes and How do you use them as request payment from Wallet?

When using bitcoin to pay at the point-of-sale or for a face-to-face transaction, there is the problem of how to communicate the Bitcoin address to be paid in a way that the person paying can use.

A bitcoin address is just data, but it is between 27 and 34 characters so that is way to much info to expect the person paying to have to manually type in.

A QR code can easily represent this amount of data in a machine-readable manner and do so reliably.  The QR code can contain other information as well -- such as an amount and a message and other fields as well -- thanks to a URI scheme for Bitcoin.

So with a mobile, a convenient way to pass that data is for the payment recipient (e.g., a merchant) to display a QR code with the Bitcoin address for the transaction, and then for the person paying to scan that QR code to obtain the bitcoin address.

A mobile app called Barcode scanner from ZXing is the most widely used app on Android for this.

If you are paying using the Blockchain for Android mobile app, then that app will let you touch the QR code button to launch the Barcode scanner app.  When the scan is complete, the Bitcoin address field (and amount field if the QR code contained the amount) will then be populated with the data from the QR code.  The person paying then hits send and the bitcoin transaction gets created and broadcasted by the mobile app.  Web-based wallets (e.g., Instawallet.org) can use a QR code as well, except the user may need manually do a paste of the clipboard contents after scanning.

The merchant or trader might use the same mobile app (e.g., Blockchain for Android) which has a built-in method to create and display the QR code for the customer to send payment to which occurs in just one step.  Many clients (including Bitcoin-Qt), EWallets and payment processors such as BitPay and WalletBit will show a QR code (or a method to get the QR code displayed) for receiving payment.

For those wishing to create a QR code manually can do so using a web-based service such as Wolfram Alpha or several other methods.  This does introduce a vulnerability however in that the provider of the QR code could detect that this is a Bitcoin address and maliciously interject another address that the provider controls -- thus directing the consumer to pay the wrong address.  So using only a trustworthy source to generate the QR codes is recommended.


Restoring from old paper Mycelium Wallet Backup

I would suggest asking this question on the mycelium issue topic. Either for android or ios. Generally for the backups in that time bip39 was a main standard as per https://walletsrecovery.org/ - mycelium was supporting WIF (wallet import format). Knowing the derivation paths, one can recover from it in the wallet that supports WIF (like electrum?).


Does using centralized services defeat the benefits of a distributed blockchain?

I'm new to this but learning as fast as I can. Here's my understanding.

  Why would someone need blockchain as a service?

There are many applications for a decentralized database. Crypto currencies are one notable use, and (I believe) where the concept started. Blockchains could also be useful for transaction processing, identity management, logistics, medical records, etc.

  The entire concept of blockchain that it is decentralized, isn't going to a blockchain service breaks the it entirly?

It depends on the purpose of your blockchain. In the case of Bitcoin, decentralization is a core concept which the entire project depends upon. If a small business wants to use this as a way to store transactional data then a couple of servers in the US may be all they need. Hence these service offerings.


You are on the right track. The address is derived correctly, it is just not encoded with the right version.

You need to add the testnet network version to the btc.payments.p2pkh call as well.

Something like this should work:

console.log(btc.payments.p2pkh({pubkey, network: btc.networks.testnet}).address);

The address should then start with m... instead of 1....

More information about the available parameters can be found here: https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/payments/p2pkh.js


No, nothing stops it.  The rules of the currency are whatever people decide they are.  If there is unanimous agreement on a change - that is, if all users adopt a patch implementing different rules - then the change happens.

Obviously this would be a bit strange if some of those coins had already been spent - they might have changed hands many times and now be held by many different people, who would be punished by such a rule. But still, if everyone adopts the patch, that's what happens.

Such a change might also shake the market's confidence in the currency.  An investor might think "The vengeful community turned on this one guy and wiped out his funds.  What if they turn on me next? I better dump all my holdings right now, before that happens."  If enough people think that way, the value of the currency crashes.

If there is only partial agreement - some adopt the patch and others don't - then the currency forks.  Some people would accept coins that originated with those first n blocks, and others wouldn't.  This situation can be very confusing if you are trying to buy something from a merchant, but they follow different rules than you do; your money might or might not be accepted.  Previous forks (e.g. Bitcoin Cash) have been relatively orderly because both sides were willing to go their separate and independent ways, and make it clear that they were two separate currencies.  (I did say "relatively orderly"; if you browse this site, you'll see lots of "halp I sent BTC to a BCH address" posts showing it hasn't been trouble-free for everyone.)  If both sides insisted that they were "the one true Bitcoin", it would be much more chaotic.


Is it possible to reverse a confirmed transaction?

No, a confirmed transaction can not be reversed.


Can the coinbase transaction be used to spend an UTXO?

It would be rejected.  The coinbase input must use a very specific previous outpoint: 0x0000000000000000000000000000000000000000000000000000000000000000ffffffff. This prevents it from referring to an actual previous outpoint.


I lose my private key on my blockchain wallet

look through all your devices that you accessed the wallet with- surely you made a copy of your private key somewhere
Only you had control of that ...
what service diod you use initially?
MEW or ? an exchange ?


In the blockchain split of March 2013, where should miners mine, 0.7 or 0.8?

You should go to 0.7, despite the fact that this is the version containing the error. This choice was made because it should be much easier to get the few who upgraded to bleeding-edge 0.8 to downgrade than to get everyone to upgrade all at once.

Sources:

https://bitcointalk.org/index.php?topic=152030
http://codinginmysleep.com/blockchain-all-forked-up/
http://bitcoin.org/chainfork.html


When Schnorr signatures are part of Bitcoin will it be possible validate each block with only one signature validation?

Yes, one validation per block, but not one signature per block.
To clear up confusion, there are 3 distinct technologies involved here:

(1) non-interactive aggregation is the ability for a third party (who does not hold any private keys) to combine multiple signatures, each with their own message and public key, into a single signature that can be verified by someone who knows all messages and public keys.
(2) interactive aggregation is the same, but when the signers need to be aware of the aggregation, and communicate with each other to jointly produce a single signature.
(3) batch validation is the ability for a verifier to verify whether multiple (pubkey,message,signature) tuples are all valid or not, faster than verifying the individual signatures. If one or more of the tuples are invalid the verifier will not learn which ones, in this case.

Schnorr signatures (and any other known discrete logarithm based signature schemes) support (2) and (3), but not (1).
The lack of (1) means there cannot be a single signature for an entire block (*), as the miner who constructs the block is a third party who isn't participating in signature creation.
Due to (2), the best we can hope for (as long as we're restricted to DL-based signatures), is one signature per transaction. Even that requires cross-input aggregation, which has complexities beyond just the implementation of on-chain Schnorr signatures (see this post for example).
However, because of (3) it is correct that there can be a single validation per block, however not a single signature per block. The speedup that is possible through batch validation does become nontrivial, in fact. Each of the 4 lines is an optimization technique that is currently implemented in libsecp256k1, which will pick the best one based on the size of the problem and the memory constraints.

(*) There exists a form of non-interactive "half aggregation" for DL based signatures, where N signatures can be non-interactively combined into a single signature of size (1+N)/2 original signatures. This could be used for blocks, though the gains aren't that great, and there are complexities around block-wide aggregation that make it less interesting.


I have more than 20 paper wallets with very little bitcoin in them. How can I combine all of them together?

You should import all the private keys and not sweep them.
Wallets like blockchain.info has this function where it will import the private key. In that case the private key will become part of the new wallet.

Import all the private keys into a new wallet. Thats it ! During spending the wallet will combine inputs from your private keys to spend required amount.


Use a converter cable. They have so many on amazon: http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=pci-e+converter+cable&rh=i%3Aaps%2Ck%3Apci-e+converter+cable


Best way to find list of UTXO related to xpub

The balance checks are cut short based on a gap limit.
A gap limit is usually set to 20, and is defined as a consecutive block of addresses with no transactions.
Since HD wallets only give out a new address on explicit request, or automatically when the previously issued address has been used, it is assumed that someone will not leave a block of 20 consecutive addresses unused.
Wallet software will generate a short list of maybe addresses when you load an xpub or other form of seed. It will then check through that, and if it doesn't find 20 consecutive unused addresses, it will generate another short list (so the first list might cover 0-100, then 100-200, etc). until it finds the block of unused addresses.
This assumption naturally falls apart if you are running an exchange, payment service, or other wallet set up where it is very likely that you will have many hundreds of unused addresses. Those systems generally keep track of assigned addresses out of band, and have specialized indexer systems that can track many millions of addresses.


What is the algorithm for generating a Ripple address from a ecdsa public key?

The process of going from a Ripple secret to a specific ECDSA private/public key (which you didn't ask about but I included it here anyway) is documented on the Account Family wiki page.

From a ECDSA public key, {X,Y}, you do ripemd160(sha256(CompressPoint(X,Y)).
That's then encoded in base58 (using the Ripple alphabet/dictionary).

You can also look at the rippled implementation or a Go implementation.


Extended Public Key 's mechanism misinterpreting in 'Mastering Bitcoin' by Andreas

I think the arrow from HMAC-SHA256 should point right to the child
  public key. Am I right??

No, there are 3 derivation functions defined in BIP32 - Hierarchical Deterministic Wallets

  Private parent key → private child key
  Public parent key → public child key
  Private parent key → public child key

The diagram above illustrates

1. Private parent key → private child key

Perhaps you're confusing this for 2. Public parent key → public child key. Another potential confusion is that this is not for a hardened child key but a normal child key, which uses the parent public key point(kpar), combined with the parent chain code cpar and the index i. These are combined and hashed to I as follows:

I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i))

I is split as shown in the diagram, where the left 256 bits IL are combined with the parent private key kpar to produce the child private key ki:

ki = parse256(IL) + kpar (mod n)

IR is the new child's chain code at that index i, and the child public key is then calculated like normal using elliptic curve secp256k1 from the child private key itself.


What can happen if/when a node is surrounded by rogue nodes?

I don't know how frequently this occurs but the Bitcoin.org client (using default settings) will, after some amount of time (in the several minutes range, if I remember correctly), intentionally drop the existing connection and connect to a new peer chosen from the list of peers it knows about.

So the duration available to the attacker to feed the node corrupt (invalid) data is not very long.

If the node will be used to honor payments on 0/unconfirmed, then a race attack is a possibility so the recommendation is to not allow any incoming transactions and to have only outgoing connections and even then only to well-connected nodes.

There is further discussion of the risks here:

http://bitcointalk.org/index.php?topic=4335.msg63432#msg63432
http://codinginmysleep.com/bitcoin-attacks-in-plain-english


BIP 32 Public Parent Key -> Public Child Key

The addition operation in that context refers to the Elliptic Curve group operation ("point addition").

The child key returned is a point, not a serialization. So the question of whether it's compressed or not is not technically relevant. In practice, every time a serialization of a point is used in BIP32, it is compressed though.


If you do this correctly, it would mirror your wallet, yes. BUT!

Doing so is probably not a good idea, because you'll have to type your seed phrase into a desktop computer that may be compromised. The point of a hardware wallet is keeping your keys locked away in a device which never touches the internet, testing your backup seed phrase on an internet-facing device entirely undermines this.

Instead, it is best to test your seed phrase using the hardware wallet itself (or, a second one).

Initialize the hardware wallet, write down your seed phrase
Open the wallet software on your PC, copy the receiving address your wallet shows into a text file
Wipe/reset your wallet, and re-initialize it using the seed phrase
Once done, open the wallet software on your PC, and check to see if the receiving address is the same as the one you copied to your text file. If it is, then you successfully recreated the same wallet.

If you've already sent funds to your hardware wallet, then it may be worth removing the funds from the hardware wallet before doing this test (or, just do the recovery test on a second hardware wallet). You wouldn't want to wipe the wallet with funds on it, before you're comfortable with the recovery process.


NVidia cards require that you install the CUDA drivers in addition to the standard video card drivers (ATI/AMD cards ship with OpenCL as part of their driver package). Without these drivers installed they will not be available to any miners.

Since the Quadro 600 appears on the list of CUDA compatible GPUs it should be mineable, though what kind of performance you'll get is questionable.


Is it true that all the bitcoins in existence are on the blockchain (the ledge), but it just depends on who the owner (address) is?

Rabbit holes are deep

Bitcoin's blockchain doesn't really know who owns anything.
Bitcoins don't exist as things whose ownership can be reassigned.
Bitcoins have no individual continuity.

Yes the Blockchain effectively keeps track of changes of something that often corresponds to what we think of as ownership of money. However the blockchain cannot distinguish between Alice sending 1 BTC to Bob (money changing hands) and Alice sending 1 BTC to a different address in one of her wallets (rearranging her money, no change of ownership).
Wallets can process transaction data to keep track of a set of unspent transaction outputs (UTXOs) removing outputs that have been spent and adding newly created outputs.
The total monetary amount of the UTXO set should add up to 18.5 million (or whatever the quantity mined so far adds up to).
However the identity of bitcoins is not preserved. It is only the total amounts that always sum up to the correct current money supply.
If you think of UTXO's as coins, the mined transactions effectively melt all the input coins down and use the combined molten metal to cast a new set of coins. No coins change hands, all coins are destroyed in every transaction and new coins created.
For example in the following transaction there is no way to say that certain inputs correspond to certain outputs. This is true regardless of the amounts although you can sometimes make inferences. An exchange might consolidate several of its users transactions into one bitcoin transaction  with dozens of inputs and dozens of outputs and there's no certain way to determine which inputs correspond to which outputs.
In block 669188 there is a transaction 1218…d33e. If you look at that in a blockchain explorer such as blockchair the details will be shown as
Senders

Amount
Address

0.00149566 BTC
3PxGWkwnxQ88zQw8TgBiYrH4pQxhakmN16

0.05809775 BTC
3CDcCbis6dEBeksMY8uYhWyU3EaLN6vh82

Recipients

Address
Amount

1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q
0.01076317 BTC

3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY
0.04809524 BTC

See footnote.
Where did the 0.00149566 BTC end up? At 1C7c…4Q1q or at 3Bwb…ECRY? No one can say, it may not be a meaningful question.
So the notion "the blockchain actually states where all bitcoins in existence are at" isn't meaningful because there are no things called bitcoins, there are only amounts of money specified in a unit of measure named Bitcoin.
The reality is simply that the total amount of mined bitcoin is kept track of as a list of amounts, each of which is associated with a bitcoin-script.

Footnote
The data under "Senders" doesn't all come from the transaction data directly.
Inputs are specified by the transaction ID of a prior transaction they were created in (received in) and an index number into the list of outputs of that transaction.
You can look at the raw data, for example by clicking on "raw data" in the Blockchair web page. It will show a Hex and a JSON view of the actual data
0200000000010274d82567d8e55f9b25628093bd151289543e8630c3f18656cfcd090953cf2ab601000000171600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9ffffffffbc06dcfee104538ef7c333cc16be005de31a4fecec6d766da23ecb2ae6bebda001000000171600148a1e82051ee5b269209d35aee915ca71c2d80a47ffffffff025d6c1000000000001976a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac346349000000000017a9147072ead5bae0971c1aed1b49b61a822b502c6b3d8702473044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b012102988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b02473044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d4012102ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d900000000

That's hard to make sense of so they provide a JSON view (or JSON interpretation):
{
  "txid": "1218039587a3fc96f0c6f3d0fb0d49404f54917a3d63cb52158a1ef84f27d33e",
  "hash": "cb44308832dfeceeba412633b937ebc3bbf5c4629a463f7fa04442b74c76d53d",
  "version": 2,
  "size": 420,
  "vsize": 258,
  "weight": 1032,
  "locktime": 0,
  "vin": [
    {
      "txid": "b62acf530909cdcf5686f1c330863e54891215bd938062259b5fe5d86725d874",
      "vout": 1,
      "scriptSig": {
        "asm": "00140cabe7062ed5a42e1c6dc75efb708e980efc9aa9",
        "hex": "1600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9"
      },
      "txinwitness": [
        "3044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b01",
        "02988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b"
      ],
      "sequence": 4294967295
    },
    {
      "txid": "a0bdbee62acb3ea26d766decec4f1ae35d00be16cc33c3f78e5304e1fedc06bc",
      "vout": 1,
      "scriptSig": {
        "asm": "00148a1e82051ee5b269209d35aee915ca71c2d80a47",
        "hex": "1600148a1e82051ee5b269209d35aee915ca71c2d80a47"
      },
      "txinwitness": [
        "3044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d401",
        "02ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d9"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01076317,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 79e947df07c7941727d79ea4cac9b909c43d3c1c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q"
        ]
      }
    },
    {
      "value": 0.04809524,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_HASH160 7072ead5bae0971c1aed1b49b61a822b502c6b3d OP_EQUAL",
        "hex": "a9147072ead5bae0971c1aed1b49b61a822b502c6b3d87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY"
        ]
      }
    }
  ]
}

Note that the two inputs listed under vin are

txid
vout
scriptsig etc

b62a…d874
1
…

a0bd…06bc
1
…

So the two inputs are specified, not using an address and an amount but by specifying a source transaction and a position in the list of outputs (vout). There is also other data, essentially proof of right to spend. So the blockchain explorer can use txid & vout as an index to look up additional details of those inputs from its records of the specified earlier transactions (e.g. "date received" for each vin)


Is there a limit on the size of the block header?

The only valid header is 80 bytes, no more, no less.

The other stated length of 128 bytes is part of the internal SHA256 hashing algorithm (its input must be a fixed multiple of 64 bytes), it's not represented anywhere in this format. Likewise, the null padding added when hashing the header is not ever considered to be part of it.


bitcond v0.12.1. "UpdateTip: 6 of last 100 blocks have unexpected version"

Yes. You can ignore this.

This means that some miners have mined (still compatible) blocks with a version number unknown to Bitcoin Core.

Generally this indicates that some miners have mined blocks that signal non Bitcoin Core compatible soft- or hard-forks. Very likely a 2MB hardfork after BIP109 implemented by Bitcoin Classic.


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.


If I lose a Trezor then how does the replacement get access to the same wallet?

Trezor implements BIP32/BIP39 (hierarchical deterministic wallet and mnemonic encoded seeds, respectively).

The mnemonic (12 words) is just a way of encoding a hex seed like 6c5f9d00018f2a2030afcc6f3057e5a4dea6dfb905dd4b0197a9a047bcfe0501662332a3caa846b1223ff3d20cfb295e7f94fe51c94472e3f8429c97754132e9 (whose mnemonic would be business weird season glimpse pole robot surprise next term toddler doctor fresh). The hex seed is then used for a master private key and a master public key pair (in this example, xprv9s21ZrQH143K29DbrSg2YgC2iyW3Gx3FhNExbxEacDWJCmz9xmsxKjon93FSC85Bv4AkszKLK1d3FA6PKS1Wb6xYotbDppezTMQaazbPL6h and xpub661MyMwAqRbcEdJ4xUD2up8mH1LXgQm74bAZQLeCAZ3H5aKJWKCCsY8FzL33Ay3XxoX7xWyq4pejzuSQEQw2hA2CvWvKBgMGTJLgZXRzdbf, respectively).

So if we look at this bip39 tool, the mnemonic business weird season glimpse pole robot surprise next term toddler doctor fresh has a list of addresses which will be used by the Trezor, in order (in this example, the first listed address begins with 18SKy...).

All of this is just demonstrating how it works (do not enter your mnemonic into a website as this example shows!), or as TL;DR: the mnemonic is all you need to recover the keys for Trezor addresses


Warning: Reducing -maxconnections from 1000 to 865, because of system limitations

Connecting to more nodes will not make you learn about transactions faster, after some point.

Your node will just be busy processing messages - including many uninteresting ones - to maintain connections with all peers, making it slower at processing new things.

Connect to a few fast peers with -addnode, or even run multiple nodes yourself, and interconnect them to each other. That will be faster than connecting directly to everyone.

The reason for the reduction of max connections is due to the limited number of file descriptors the operating system granted your bitcoind process. You can use the ulimit shell command to increase the maximum file descriptor.


ECDSA Input When Transferring Bitcoin From Owner A to Owner B

1) I don't see exactly where Bob's public address is used other than to populate the new transaction record. Does it mean that once the transaction is confirmed, Bob can just see it in his wallet and only he can spend the coin in that transaction because only he has its private key?

Addresses are a human abstraction and they don't appear anywhere in a transaction. Transactions are a combination of Inputs and Outputs.

Outputs contain the amount transferred and some conditions attached to redeem the coins (known as scriptPubKey). Inputs redeem previous outputs by providing the inputs needed to validate the sender's conditions (known as scriptSig).

The most common set of conditions are "whoever can provide a signature associated with this public key can redeem the coins".

  2) What data elements, specifically, are in the message (highlighted above)?

What exactly is being signed is a variation of the transaction itself. Which variation depends on a flag called sighash which is attached to the signature.

  3) Bob's Public Address is actually Base58 encoded. Does that mean that when the new transaction for Bob is created, the Bitcoin client first decodes the Base58-encoded Public Address back to a Public Key so that it's the Public Key that gets stored in the new transaction record rather than the Public Address?

No, the public key is hashed before being encoded into an address. Hashing is a one-way operation so you can't derive the public key by knowing the address. The client that wants to validate the transaction just runs the script with the conditions that the sender attached (public key) using the inputs that the person that is trying to redeem provided (signature). If the script evaluates to true the transaction is valid. Scripts contain public keys not addresses.


Mining Difference with Multiple Rigs between Bitcoin and Zcash

There is no difference between bitcoin and zcash here, mining with multiple machines work the same way.

If you have 2 machines they can mine in the same mining pool or separate pools. You choose.

Your machines are never competing against each other. You are the one that get paid for the work of both machines.

If you are solo mining instead of using a pool, the machines are still not competing against each other. They are both trying to find a block for you, the owner.

The bad thing you want to avoid is having both machines do the exact same work. That would be a waste. The second machine wouldn't be doing anything useful. Handing out duplicate work would be a serious fault in the mining pool software.


What is the origin of the data that the bitcoin algorithm operates on?

The proof of work that miners do is a double sha256 hash on 80 bytes of data.

Where do the 80 bytes come from?

They are build from enough data to describe the current block (and the transactions it contains) and a pointer to the previous block.

To wit:

4 bytes version number
32 bytes hash of the previous block
32 bytes Merkle root of all the transactions contained in this block
4 bytes timestamp
4 bytes current difficulty target
4 bytes nonce

These 80 bytes are concatenated and have the shit sha'd out of them until the required difficult is reached.

More info


What happens if nodes have different P2P versions during discovery?

If the nodes are running different versions then communication cannot continue.

That is incorrect. If two nodes interact which have different versions, they just communicate using the lower of the two versions.


How to do precise accounting with bitcoind?

That feature has been requested but is not implemented in the Bitcoin.org client:

https://github.com/bitcoin/bitcoin/pull/283

Armory may be getting this feature.  See discussion in the README:

https://github.com/etotheipi/BitcoinArmory#readme


The best description of XRP distribution/giveaways I've seen is on Ripple Labs XRP Distribution web page.
The whole page is worth reading, but I'll just include a few select quotes that may address the question:

Users don’t need to hold XRP if they prefer to transact in other currencies (e.g. dollar, euro, yuan, gold).

…

The inventors of the Ripple protocol created 100 billion XRP at its inception, and no more can ever be created according to the protocol’s rules. The creators gifted Ripple Labs 80 billion of the 100 billion XRP in existence.

…

Ripple’s method of confirmation, called consensus, doesn’t need mining; therefore, it requires comparatively negligible computing power, confirmation time adapts to network latency, and transactions are immediately irreversible once confirmed.
Because Ripple’s new architecture does not require mining, the creators of Ripple had a choice: distribute XRP exclusively via mining or diversify the distribution methods.
Distributing value is a powerful way to incentivize certain behaviors. Bitcoin’s mechanism, for example, led to an explosion of processing power devoted to bitcoin mining. Our goal in distributing XRP is to incentivize actions that build trust, utility and liquidity in the network.


Different redeemScript for the same scriptPubKey?

A P2SH transaction will execute whatever redeemScript you provide, which must be a standard transaction:

  Transactions that redeem these pay-to-script outpoints are only
  considered standard if the serialized script - also referred to as the
  redeemScript - is, itself, one of the other standard transaction
  types. See BIP16

Those standard transactions, like a P2PKH does require a signature, so even though you provide the right redeemScript, if it doesn't execute successfully, the entire tx will become invalid.


It's not possible to recover your coins unless you have a backup of the wallet.dat file. If you had a notable amount of coins, you can try using a file recovery software, although I believe they can't recognize wallet files.


Zero to Bitcoin in sixty seconds - how to set up a Bitcoin client in case you need it fast?

Well, I would run the bitcoind in a VM, and regularly snapshot it.  If it fails, rollback the snapshot and reboot. Back online in < 10 min, assuming frequent backups and you start working right away.  Not sure if this is the use case you're asking about, but that's what I'd do for max uptime.


Blockchain fees $100 for $1000 !!! Please help

You cannot change this.  It is a design limitation of the network. Continuing reading for an explanation.

What blockchain.info is referring to is the data size of your transaction. Bitcoin fees are based on the data size of the transaction, usually marked as a btc/byte value.

Transactions can vary a great deal in size because of the number of inputs and outputs. Any bitcoin address you have is actually made up of all the inputs it has received. If you have received 10 transactions into a single address, emptying the address will require all 10 of those inputs plus at least 1 output. This adds data size to the transaction, therefore it requires a higher fee.

Blockchain.info is telling you this is the case with your address, and it's not particularly unusual. I had an old address that served as my mining receiving address for several years. It just collected mining profits in small chunks over all that time. When I finally decided to move all of it, there were 72 inputs and one output, amounting to a massive fee. It kind of sucks, but that's one of the limitations of the network.

One thing to note is that mining fees are entirely unrelated to the value of bitcoin or the sum of the transaction outputs. Fees are only based on the data size of the transaction. A 100 bitcoin transaction with only one input and one output will be a significantly less fee than a 1 bitcoin transaction with ten inputs and ten outputs.


Why are the offers to buy Bitcoin on Bisq always way over the market price?

It's a combination of the low trade volume, and also because the traders on Bisq know that some people will pay a premium in order to avoid having to complete KYC requirements to do their trades.
If you signed up for an centralized exchange, you'll be able to buy at the market rate (minus a fee), but the trade-off is having to complete KYC requirements.


I sent money to a bitcoin wallet from Blizzcoin and there's nothing there?

According to blockchain.info the coins weren't sent yet.

Here's a post from another blizzcoin customer saying that it took 2 days for his purchased coins to be sent:

  apparently because I Manually transferred money to them instead of ordering through their web interface, it wasn't an instant transfer of bitcoins.

Could that be your problem too?  How long has it been since you sent the money to them?


How do you push a transaction to the Bitcoin Cash Network?

I have listed a lot of Bitcoin Cash block explorers here, and most of them are Insight block explorers so I thought they should have Insight API. I checked all of them and the ones with API are:

Bitcoin.com: https://cashexplorer.bitcoin.com/insight-api/tx/send
BlockDozer: https://blockdozer.com/insight-api/tx/send
Blockexplorer: https://bitcoincash.blockexplorer.com/api/tx/send


LiteCoin Wallet balance does not match block-explorer.com

Not all of the addresses in your wallet are displayed in the QT client. There are certain addresses called change addresses which your client creates automatically when you send coins and have some left over. Those are still part of your wallet, but are not displayed.


The disadvantage of merged mining is the additional coin daemons you have to run in the background. They all use disk space, memory, cpu cycles and bandwidth. A more annoying issue is that most of them are no longer maintained and have bugs. You may find that they crash frequently - at least namecoind does.


Bitcoin Cash totally different from BTC?

BTC and BCC share a transaction history. Thus, to each blockchain, anyone holding a coin before the split has a coin in their address on each blockchain.


Will a zero-fee transaction get processed faster if I send it straight to a miner I am running especially for that purpose?

This will let you include your own transaction in the next block you find yourself, without paying a fee (but the fee would be paid to yourself).  However, if you are a solo miner, it will probably be an extremely long time before you find a block yourself.  It won't have any effect on whether other miners will accept your transaction without a fee.

There's no free lunch as far as getting fast transactions without a fee.


Is a timestamp in bitcoin different than just the "stamp of time"?

Update: There is some discussion about timestamps here- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018251.html

When a Bitcoin block is produced there are essentially two times involved:

The timestamp in the block header, put there by the miner
The actual time the block was produced.

Bitcoin has two mechanisms to protect against miners manipulating the timestamp:

Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks. The median of eleven blocks implies six blocks could be re-organised and time would still not move backwards, which one can argue is reasonably consistent with the example, provided in Meni Rosenfeld’s 2012 paper, that six confirmations are necessary to decrease the probability of success below 0.1%, for an attacker with 10% of the network hashrate.

Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard. It should be noted that unlike the MPT rule above, this is not a full consensus rule. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.

Source: https://blog.bitmex.com/bitcoins-block-timestamp-protection-rules/


How to return Tx to mem pool from orphan block

Proto code for returning transactions from orphan block:

foreach ( tx: orphanBlock )
  if ( tx.isValidAfterReorg ( ) )
    mempool.insert ( tx );


Is support@pi.uk.com the real blockchain.info's support address?

That's the address I used to contact Ben Reeves (blockchain.info's author) a few months ago, so it should be correct. Whether it is still in his control is a different question. He is also known as piuk in the bitcointalk forums.


The bitcoin client will first try to scan for previous known IPs, once that fails, it will indeed fall back on DNS seeds.

It will resolve seed.bitcoin.sipa.be to a list of IP adresses and it will pick one of them.


If you're using Bitcoin Core, you must first import the private key using the importprivkey console command.  The coins held by that private key will then be added to your existing balance (if any).

If you want to spend those specific coins rather than some others in your wallet, you can use the "coin control" feature.  This can be enabled in Settings:Options:Display; when you send coins, you will be offered a list to select which addresses/transactions you want to spend from.


What prevents a node from receiving a solved solution and claiming it as its own work?

Do you modify the block or do you not modify the block?

If you don't modify the block, it still pays the mining reward to the same account. So you've just done what everyone wants you to do.

If you do modify the block, it won't be valid anymore until and unless you mine it. That leaves you two choices:

1) You can ignore this block and mine some other block. But then someone else who mines on top of this block will have a longer chain than you and you won't get any reward. So why would you do this?

2) You can mine on top of this block. Well, that will just help ensure the person who mined that block gets their reward by producing an even longer chain that includes their block.


What would be the technical, and wider, implications of a cryptocurrency that used proof-of-disk-space?

I'm speculating here, because I'm not going to test anything out.

The IOPS would like shoot through the roof. The potentially large amount of writes and reads will likely affect disk life, especially if the disk is an SSD. It would generate excess heat. A magnetic disk would also generate constant vibration. Heat can be controlled easier than GPU or CPU heat because there's less of it, and vibration can be dampened using rubber mounts. The largest risk is simply drive failure due to above average activity.
The GPU would likely be idle. The CPU would only be necessary to drive the hardware operations.
I think it may be difficult to get a 3 TB drive for that new gaming rig, because all of the miners would be trying to pack as much disk space into a device as possible.
I don't know enough about the manufacturing process to hypothesize accurately.
I could see a lot of need for drive recycling. HDDs burn out a lot quicker and take up a lot more waste weight than CPUs and GPUs.

What's interesting about the proof-of-storage-space concept is that it can really take advantage of unused space on consumer devices. I know I've got a 500 GB hard drive in my work computer that has never seen more than 50 GB on it. Amalgamate that across a corporate network, and there's probably PB of space available! I could see malicious types taking advantage of this in malware pretty easily, too: high CPU or GPU usage causes lots of heat and terrible performance, while high HDD usage can just make a program take a few seconds longer to start up.


How does the pool know the share hashes are calculated and not cheated?

If the hashes are not recalculated/checked by the pool independently

The hashes would be checked by the pool, so you can't just submit random numbers. Pools would most likely ban miners which did that, for wasting their time.


Do you know one of the addresses in the keychain? Ledger uses BIP44 derivation so you could write a loop to check different seed phrases and check the resulting addresses against an address you know that should be in the keychain. This way you can type in your recovery words without having to be online.

For example if it were me I'd probably write something using the bitcoinjs-lib. Here's a start written with bitcoinjs (NOTE I'm using version 3.3.2). This will take a recovery seed and an address and it will search the keychain and tell you whether or not the address exists within it.

//var words = "segment increase inch ensure corn cigar suggest fetch output proof peasant enact";
//var addr = "1c4XzQx7Uh8CnxzAN5CRrUjkbxGB1GUWp";

var searchbtn = document.getElementById("searchbtn");
searchbtn.onclick = function(){

    var words = document.getElementById("words").value;
    var addr = document.getElementById("addr").value;
    var depth = document.getElementById("depth").value;
    inkeychain(addr, words, depth);
}

function inkeychain(addr, keychain, depth){
    var isfound = false;
    for(var i=0;i<depth;i++){
        var seed = hd.bip39.mnemonicToSeed(keychain);
        var root = b.bitcoin.HDNode.fromSeedBuffer(seed)
        //const root = bitcoin.HDNode.fromSeedHex(seed.toString('hex'))
        var wallet = root.derivePath("m/44'/0'/0'/0/"+i);

        //legacy
        var address = wallet.getAddress();
        var wif = wallet.keyPair.toWIF();

        //segwit p2sh
        var pubKey = wallet.keyPair.getPublicKeyBuffer();
        var pubKeyHash = b.bitcoin.crypto.hash160(pubKey);
        var redeemScript = b.bitcoin.script.witnessPubKeyHash.output.encode(pubKeyHash);
        var redeemScriptHash = b.bitcoin.crypto.hash160(redeemScript);
        var scriptPubKey2 = b.bitcoin.script.scriptHash.output.encode(redeemScriptHash);
        var p2shsegwit = b.bitcoin.address.fromOutputScript(scriptPubKey2);

        if(address===addr){
        isfound = true;
            console.log(address, wif);
            $('#result').html('Found '+addr+' in this keychain at '+i+' position in the keychain');
            alert('Found!');
        } else if (p2shsegwit===addr){
            //check for segwit p2sh
            isfound = true;
            console.log(p2shsegwit, wif);
            $('#result').html('Found '+addr+' in this keychain at '+i+' position in the keychain');
            alert('Found!');
        }
    }
if(isfound===false){
    $('#result').html('No matches');
}

}

https://bitcoinfunction.com/?id=5d9ea508d9bed

From here you could take it a step further and make the words variable an array with all your different combos and then loop them all through.


Calculate the hash of mined block using stratum parameters (coinb1, coinb2, xtranonce1...)?

When a pool gives a miner data to mine it is not data for one specific block, but a template for a block. The miner hashes many variations of this block data to try to find a block that has a hash value below the current target (which is determined by the current difficulty).

To calculate the hash of a block on the blockchain given only the data that the miner was given from the pool, you would have to do the same thing the miner did. You would have to hash many different blocks in search of that low hash - only then would you know the exact data the block contains - assuming you are not allowed to look at the block data on the blockchain.

For the old getwork protocol the pool would only allow you to set the nonce value in the block header. Everything else in the block was determined by the pool server. So you would have 4 bytes (32 bits) to search to rediscover the block someone mined with the given getwork-data. That's 2^32 (4294967296) different blocks. On average you'd have to search 50% before finding the right block. That's 2147483648 hash operations to perform on average. This is done in an instant with modern mining hardware.

With the Stratum protocol it gets worse. Stratum allows the miner to modify the nonce and a part of the coinbase transaction called "extra nonce 2", the size of which is determined by the pool, but usually 4 bytes. This means the miner has 8 bytes (64 bits) to fiddle with. That's a lot of blocks to search through. 2 to the power of 64. Though on average you'd only need to try 50% of those blocks.

It's actually a bit worse than the above because the miner may have also changed the timestamp on the block (ntime field of the block header). It would be a value close to the original timestamp though.

Usually pool servers push new work data to miners quite often. If you have equally fast hardware to that which found the block, then you should be able to do the above search in less than a minute. But that assumes that your miner and the one that found the block search the nonce and extranonce2 (and ntime) in the same way. For example if both miners start with a value of zero for nonce and extranonce2 and then increment from there, then it should not take long at all.


How to transfer blockchain between two machines?

A node won't sync blocks from another node (peer node) if the peer node is not fully synced. There might be a message in your debug.log that says as much. Your best bet is to wait until node A is fully synced.

This is the only reason the node won't sync.


Regrouping accounts belonging to same user

First off, you should really start thinking in terms of addresses rather than accounts, especially when doing block chain analysis.  See here:  What is the difference between accounts and adresses?

You should also start thinking about transaction inputs not in terms of addresses, but rather unspent transaction outputs (UTXOs).  Each UTXO will generally have an address associated with it, but in the case of multisig, may have several addresses in a single UTXO.  So in this case, even a single input to a transaction has more than one person associated.

There are also the cases of coin mixers, web wallets, and exchanges, which often create single transactions that include many inputs and many outputs, all coming from and going to different people.

So to answer the question, no, you cannot assume that all addresses used as inputs to a transaction come from the same person.


If you are using WordPress to create, manage the website and something like Woocommerce plugin to manage the subscriptions/memberships, BTCPay will help you accept bitcoin payments: https://docs.btcpayserver.org/WooCommerce/
There will be no address reuse and all your issues will be resolved.

How can members prove that they paid the fee ?

Transaction details, Invoice etc.

What do I have to get from members to prove it?

Reusing address is not a good practice. Membership websites can manage things differently and use new address for each membership payment. Once the transaction is confirmed it is updated in the database for the user automatically.

how app should check and verify the owner of transaction ?

Owner of transaction should have credentials to login and use the membership options. App will check the database and know if user has paid for membership or not.
If you are using something else to create the website and manage subscriptions/memberships, I would suggest creating an issue in BTCPay GitHub repository and share relevant details.


Each full node maintains a score for the peers it has connected to called banscore. Any 'mischief' on the part of the peer result in an increase of the banscore. When banscore reaches 100, the peer is in most cases disconnected.

When a node receives a transaction from the peer, it will verify the transaction and signature check forms a part of this verification process. If a malformed transactions gets continuously sent from a peer, the node will simply disconnect itself.


Samourai Wallet on Android and Billion app on iOS.


Receive payments in BTC or USD, but get paid in Bitcoin?

NO . . .  you cannot sell Bitcoins to a customer to pay yourself Bitcoins.  They - the  customer need to buy Bitcoins to have ready to pay for the website item and you need to send a bitcoin price and address to them based on a price you have converted to bitcoin from USD.

The question whether you want to keep the bitcoin as bitcoin will be determined by whether the price of bitcoin is rising or falling.

It is not as easy as you think - our website accepts bitcoin - and we have to cancel the order in a given time frame because the price of bitcoin keeps changing so fast - and either we would loose or the customer would be be pissed because they pay at the quoted rate and by the time they do pay it has gone up - and then they want "change" back based on the time they pay.

Yes . . . there are API's yes - and it is a complicated process to use them because of just what I said above - and you need to be a database programmer in some language like PHP etc to write the code for your site usually becasue cron is going to be involved and you will need elevated privileges an "el cheapo website from GoDaddy or Hostgator etc will not have and even their VPS packages normally will not do - and it matters then whose exchange you are tied to by the API you use because their prices vary even between the current pricing


I need help with an bitcoin open book exam

BIP 84 specifies how zpubs work. BIP 32 specifies how derivation paths work.
According to these BIPs, the zpub will be used as the master public key, and the CPK (Child Public Key) function should be applied to the zpub to yield the specific public key you desire.
BIP 84 specifies that zpubs are used to derive P2WPKH addresses, so the public key should be converted to a SegWit address (bc1...).
If you are familiar with Elixir, you can use this library, to which I've added bip32 support.
https://github.com/sachinmeier/bitcoinex/tree/sachin--add-bip32
zpub = "zpub6nQF4m3JT6hTkQ4o9Vc8LDMQx7nMkT5CsnPgVHnnrpF9JHeP6ioboEK2CXB34Xn6nzqcJnLPuMqQaKqBhwvZR7GJNvSeRUpDpCaVu3N3stz"
Bitcoinex.ExtendedKey.parse_extended_key(zpub)
|> Bitcoinex.ExtendedKey.derive_public_child(0)
|> Bitcoinex.ExtendedKey.derive_public_child(2)


Cost of single vs multiple outputs to the same address

A transaction that has multiple output scripts that point to the same address would be no different from a transaction in which every output script pointed to a different address. So when you have two outputs to the same transaction, all that matters is that you have 2 outputs and the size of those outputs (byte-wise).

Transaction priority is calculated as follows:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

As you can see, only the tx size matters and the input value and age. None of these are influenced by the address to which coins are sent.


Since we only need 450 Watts per board and 950 Watts PSU1 and 850 Watt PSU2 worked. Make sure you turn on PSU2 After PSU1 as the S7 manual says.


Sending Bitcoin to a wallet but user has not received

At time of writing, that transaction has 287 confirmations. That means it has been definitely incontrovertably irrevocably received. There can be no doubt about this. For large amounts, 6 confirmations are regarded as conclusive, for small amounts many people accept 1 confirmation. 287 is far far far beyond doubt.

The blockchain is the only truth. All data about location of Bitcoin money is in the blockchain and nowhere else†.

There is no moment in time when Bitcoin is in transit, it is always either considered by any node in the Bitcoin network to be in your wallet or in the recipient's wallet and nowhere else.

The recipient has received the money. If they say they have not, either ...

you sent the money to the wrong address, or
their wallet is not telling them the truth
(perhaps it isn't synchronised with the blockchain) or
they are mistaken or
they are lying to you.

† Use of Lightning network and other off-chain systems should almost certainly not be regarded as actual Bitcoin movements until recorded on the blockchain.


Safest method while actually logging in and using blockchain.info wallet

The key to security questions is asking what you want to be secure from. The most obvious problem you will want to avoid is losing your bitcoin to some attacker. If this is the only objective you have, it is easy to see that TOR will probably not help you: It only introduces more nodes to pass your traffic, not extra encryption security. But if you have some additional objectives, such as maintaining anonymity, TOR might help as part(!) of a much more difficult solution. For the rest of my answer, I will assume that not losing your bitcoin to a cybercriminal is your only concern.

Cold storage is a good start, and by offline storage usually being tangible physical storage, your own intuition is probably rather good at understanding all issues there. Moving to the moment when you move bitcoin back from cold storage to a wallet, the issues are obviously the transport and the execution environment of the bitcoin client through which you use the wallet.

Blockchain.info provides a fairly reputable wallet service that claims to not actually move enough information to their servers for that side to be a security concern (and they appear to run an open source wallet, with code on github). But what guarantees do you have to trust that this is and remains the case for you? If you value safety against being lied to (and be it only by some secret order to blockchain.info or because whoever may hack them might be as vile as to change things without asking for their approval first), then this is not a perfect solution---but you may decide to put more trust in them than in maintaining a safe execution environment for a bitcoin client on your own computer or smartphone. In one aspect, however, their wallet service may be particularly bad, though: Being in large part client-safe based (such that they alone can claim not to have their private key), obviously even using them you are exposed to the risk of your browser/computer being hacked in a way specifically aimed at hijacking your bitcoin transaction by changing its destination.

Using a browser app to access blockchain.info would probably protect against nothing else but you mistyping their URL to something registered by a cybercriminal. As crazy as this sounds, it is not without value, but compare that risk to the risk of forgetting to never install any other browser app (these things can get access to just about anything that happens inside your browser, hence quite likely to everything needed to hijack a transaction you make thourgh blockchain.info).

The best thing would be to have a completely self-contained box where your private key never needs to leave it, but from where you could make bitcoin transactions by entering the necessary info (destination address and unspent input tx), signing them, and outputting the tx that needs to be passed on to the bitcoin network. Such hardware bitcoin clients exist, e.g. TREZOR or Bitcoincard. However, I haven't looked closely at either, so please don't understand this as endorsement about their design or structure---in fact, from just a cursory look, I feel that maybe I should warn you about Bitcoincard pitching the inherent, well, surveillance-like data mining benefits to merchants installing supporting infrastructure. I suspect this list is not complete; I've heard an idea somewhere about putting such a client into (or via a shim on top of) a phone SIM card, and apart from the obvious question of how to secure the rest of the hardware you would use to interact with it, love the idea for its potential low cost yet more-secure-than-a-smartphone-app aspect. If I wasn't busy with another project, I might try to make that happen myself!

But back to the last part of your question: Let us assume that you stop using a third-party service like blockchain.info and run a bitcoin client on your own "physical system" as you write (I'll assume computer/smartphone), and that those best practices you mention are sufficient to keep unwanted malware and the like out of your computer (and whatever internal part of your network might handle sensitive information like your bitcoin address' private key). That may be overly optimistic, as I guess the NSA leaks we've seen make it fairly clear that this situation is very nearly impossible to maintain with personal computing equipment not specifically dedicated to, designed and hardened for a single use, at least not against a sufficiently determined and equipped adversary---but that part of computer security is better addressed elsewhere on stackexchange anyways. Still, if we can assume all that, or are simply not worried about such adversaries becoming interested in petty crime such as taking bitcoins, the obvious remaining attack vector is the bitcoin client itself. If any such client has an undiscovered bug that allows stealing bitcoin, then chances are it could be discovered after an exploit. You would minimized your exposure by using the latest version of such a client offline to create the transaction you intend to make (which may require use of a command-line interface on some clients). In fact, if you then take that new transaction and transfer it to a different system not in possession of your private key, you can completely isolate the first computer from the internet and hence any attack coming from the internet.

Obviously there are non-network based attack or loss vectors, like physically stealing one (or losing all) your cold storage device (paper?). With their own potential solutions.

But there is one well-known (and fairly obvious, to a cryptographer) potential problem that can be exploited even without your wallet being in any way connected to the internet: The private key to your bitcoin address may be weak in the sense that someone can guess it. There are two obvious causes: Either you have a brain wallet with a guessable passphrase---an easy mistake to make accidentally, as it is hard not to see how e.g. a phrase you thought you had invented yourself really happens to be printed somewhere in a book that an attacker uses to guess bain wallets, just because some author stumbled across the same idea for a sentence or phrase. Or else the software you used to generate your bitcoin address has a bug that leads to a weak key, which has already happened, leading to the discovery of a very serious defect (see this Guardian article) in the Android random number generator.


Primecoin mining is doubly competitive (in the sense you described). In fact, the amount you will mine with given power is inversely proportional to the cube of the total network compute power.

As in Bitcoin, a difficulty parameter adjusts based on the mining rate to achieve a desired block frequency. Not only that, but the mint rate is inversely proportional to the (square of the) difficulty. Unlike Bitcoin which has a fixed schedule, which at worst can be slightly accelerated with increasing mining power, in Primecoin the total number of coins that will ever be generated will decrease with increasing competition.


What happens to transactions in the mempool when their parent transaction expires?

Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well.
When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (timeout for orphan tx cache eviction), and it passes policy checks on its own txA would be added back to the mempool.
Note that the peers would only request it if we send them an inv for txA.
However, there are no such thing as "propagation as a unit" on the P2P network currently (package relay design is being discussed here). This is the reason why in your example txA must pass the policy checks on its own.
This has implications on L2 protocols with pre-signed transactions, for example in the Lightning Network where the transaction relay is critical. A pre-signed txA which happens to be below most of the network mempool minimum feerate at the time of broadcast won't be accepted even with a high fee-paying txB (1)(2).

(1) This is the reason why the Lightning protocol kept the update_fee message even post anchor outputs.
(2) This has implication in other L2 protocols too. For example in Revault it could prevent one to unvault a vault until the mempool backlog is processed.


How do I transfer btc from Core that never finishes syncho to another wallet?

Even though your wallet is still syncing you can use the debug console or bitcoin-cli along with dumpprivkey to get the private key of one of your wallet addresses. You can then import the key to an SPV wallet.


I hope that "longestt chain" actually means "most proof of work" rather than "most blocks"!

It is exactly that: the "longest chain" is the one with the most work, not the largest block height.

If it wasn't like that, then an attack like the one you described could work.


Upgrade from Bitcoin QT 0.8.5 to latest Bitcoin Core 0.15.X

Go to Bitcoin 0.8.5 Console Window and run :

dumpprivkey "myaddress"

Then in bitcoin 0.15.1

 importprivkey "mykey"

if you don't need to unlock your wallet even if it's encrypted since you are using Bitcoin-qt not RPC commands and you've already set your password when you started it.

if you don't want to use bitcoin-qt. go to terminal and run on v.8.5.0:

unlock your wallet if encrypted

(space)bitcoin-cli walletpassphrase "passphrase" timeout

Get private key of any address:

(space)bitcoin-cli dumpprivkey "myaddress"

if your wallet is encrypted run:

(space)bitcoin-cli walletpassphrase "passphrase" timeout

Then go to the latest version and run:

 (space)bitcoin-cli importprivkey "mykey"

The space before the commands is important to the command will never be saved to logs.


What are some of the pitfalls of a 100% proof of stake currency (pos) like NXT?

One can verify legitimacy of a Bitcoin branch simply by checking proof-of-work of the block headers. In Nxt it's necessary to know who the owner of the coins, so the whole blockchain data must be downloaded.

This seems to be the only fundamental pitfall that arises from very nature of Proof-of-Stake cryptocurrencies.


How to structure a Bitcoin charity miner?

You can give someone the necessary credentials to mine on your behalf without them gaining access to the bitcoins. Pools don't use the worker passwords sent with getwork for logging into the website and controlling where coins are sent. They are used only for fetching work and delivering the results.

As you say, basic auth over unencrypted HTTP is already unsafe handling of the worker passwords. You have to assume that those passwords are compromised anyway.

I think the most damage someone can do is to overload a pool server using your worker credentials. I suppose this could get your account temporarily banned, but I'm sure a pool operator would be understanding in this case. I've never heard of anything like that happening either.


The Ethereum gas limit seems prohibitively low. Will it ever be raised? If so, when and how?

The block gas limit is determined by miners. According to the Ethereum protocol, they can raise/lower it by 1/1024 of the previous block.

Currently (11/20/2015), geth is set up to automatically increase the gas limit if the previous block used more than ⅔ of the previous block gas limit and automatically decrease it if it’s below the threshold. In practice, an increase (probably) never happens, and even if it does, most blocks are well below the ⅔ threshold, so the limit would fall back to pi million quickly. Gas usage is very spikey like that. See http://stats.ethdev.com

Furthermore, for miners to amend the ⅔ logic, they’d need to alter geth’s code and build from source which is not going to happen en masse.

There are ongoing discussions about what to do about this on https://gitter.im/ethereum/research. Vitalik floated the idea of making the limit 4x its current limit and leaving the ⅔ logic the way it is. I support the 4x increase, but I think the ⅔ logic needs to be rethought.

UPDATE: I asked Vitalik about the low gas limit during DEVCON1. The reason there is no rush to raise the gas limit has to do with block propagation times. Every node in the ethereum network has to execute every transaction. If the gas limit were increased substantially, there might be delays in block times which would cause the network to go from 17 (current average) up north of 20 seconds. That's not the direction we want to be heading in.

I'll also say that one benefit of a low gas price is that it forces contract authors to create efficient code which, in turn, reduces blockchain bloat.


Ditto. I found this and am trying to implement it.

Apparently, you create a private testnet with low difficulty. I guess I'll go to lunch, because it apparently takes about an hour to do my "genesis block."

https://github.com/freewil/bitcoin-testnet-box

Be clear to stay away from the SourceForge one! Its instructions are out of date.


Why do some Bitcoin Core "good first issues" require scripted-diffs?

From the Bitcoin Core developer notes, when the bash script is included in the commit message the "Travis CI job checks that the result of the script is identical to the commit." It also makes it more efficient to review for reviewers if they can review and run a bash script rather than needing to do additional checks that the PR covers all the cases it should.
With regards to the scripted-diff examples looking complicated you can look through other examples in the Bitcoin Core repo by running:
git log --grep="-BEGIN VERIFY SCRIPT-"

Alternatively here is a simpler example that you can start from if you are trying to do a basic find and replace exercise.
For more information on scripted-diffs see Jon Atack's personal notes on scripted-diffs.
If you need help writing your bash script you can ask questions on #bitcoin-core-pr-reviews on IRC.


The only way to know which pool has mined a particular block is by identifying data that miners include in the coinbase transaction. However care must be taken as this data can be faked. Also many mining pools omits this, which is why there are many blocks that are from "unknown" miners.

Let us take the last block mined by BTC.com, which is #572639. To look at the coinbase data, you will need to look at the first transaction included in the block which is 806e80560f7c87059b9103d8bd4fca7be14810af47940c40464276d971fd2625. After you decode this transaction you will get the following input:

"vin": [
        {
            "coinbase": "03dfbc080479b0bc5c672f4254432e434f4d2ffabe6d6d6b01cdd5d0aa44ffa14f158f90119afef5e5440b5f6ff324e74a988e6db4294d0100000000000000cb2b382f00005a2197460000",
            "sequence": 4294967295
        }

In the coinbase data, pay close attention to the part 5c672f4254432e434f4d2f. This data is included in all blocks mined by BTC.com pool. If you decode this you get '\\g/BTC.com':

>>> pool_data = '5c672f4254432e434f4d2f'
>>> bytes.fromhex(pool_data).decode()
'\\g/BTC.COM/'


Will bitcoind import private keys for multi-sig descriptor with watch-only flag set to true?

I have tested setting watch-only to true and it gets rid of the errors and the node can still sign.


Just for fun. Many actions can't be explained from the point of view of logic


The length of the Bitcoin's private keys

Bitcoin uses the secp256k1 elliptic curve with 256 bit private/public key pair cryptography to render ECDSA functionality. The two bitcoin explorer (bx) commands below replicate statements/results in the site references above. Note the private key is a 256-bit hexadecimal encoded number.

% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx base58check-encode -v 128

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF - is the associated uncompressed private key that is encoded using base58 check, also called Wallet Input Format (WIF).

% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx ec-to-public -u | bx ec-to-address -v 0

1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj - is the address corresponding to the associated uncompressed public key.

If I were a hacker that wanted to compromise secp256k1, I would first compromise the top 100 rich list wallets that are not using multisig first.  Bitcoin is the most excellent canary in the cryptographic coal mine to determine when secp256k1 fails. The banking system would never be such a good crypto-Samaritan.

From Table 1 the elliptic curve subject matters experts assert the strength of a 256-bit secp256k1 private key has the strength of 128 bits of encryption when the associated public key is exposed.  To brute force attack a public key to obtain a public key with 128 bits of entropy will cost at least $100M in electricity at 5 cents per KW-Hr using almost perfectly efficient quantum computers. It is mostly supposition to arrive at projections for when an mathematical back doors for compromising secp256k1.

You can read about Shor's algorythm.  The Bitcoin Community is very shrewd concerning planning for quantum computing attacks. Also, the NSA issued some interesting warnings concerning Suite B technology a few months back, but those pages are no longer publicly visible.

No telling what path the Bitcoin community will take, but I assure you the hardfork will be much faster than trying to double Bitcoin's maximum blocksize.


Does Bitcoin Core know how to prune the existing database or will it start the entire sync process over?

It knows what to do and you will experience no resync or reindex when you do the pruning process (barring any unclean shutdowns or sudden power loss). There is no noticeable effect when pruning except that the size taken up on disk is much smaller.

  How much free disk space does the process require?

No additional space is required. Disk space will be freed up by pruning, not consumed.

  Will the pruned .dat file be deleted by the process?

Yes, that is how it frees disk space.


How to add a signature to a transaction which I can broadcast

How can I attached this signature to the transaction so that I can
  broadcast it to network?

This is more agnostic to any particular wallet software, but I hope it's helpful. When you sign a transaction, you then put the signatures in the scriptSig field of the input it corresponds to (the tx may have multiple inputs).

For a m-of-n multisig transaction, the scriptSig format is:

0 <sig1> ... OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

To broadcast it to the network, you can use the broadcast command in electrum:

cat signed.txn | electrum broadcast -

If successful, the command will return the ID of the transaction.

Alternatively you can use the sendrawtransaction RPC on a node running Bitcoin core.

sendrawtransaction "hexstring" ( allowhighfees )

Submits raw transaction (serialized, hex-encoded) to local node and network.

Also see createrawtransaction and signrawtransaction calls.

Arguments:
1. "hexstring"    (string, required) The hex string of the raw transaction)
2. allowhighfees    (boolean, optional, default=false) Allow high fees

Result:
"hex"             (string) The transaction hash in hex

Examples:

Create a transaction
> bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"
Sign the transaction, and get back the hex
> bitcoin-cli signrawtransaction "myhex"

Send the transaction (signed hex)
> bitcoin-cli sendrawtransaction "signedhex"

As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["signedhex"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


Electrum Wallet How to use "Child Pays for Parent"

You can't use CPFP to confirm that transaction. It's impossible for one to rescue a low fee transaction using CPFP, unless he/she has a private key of at least one ddress of that transaction's outputs (in your case, it's impossible, because you don't).

That transaction's receiver can do CPFP, if he/she wants.

Hint: Use RBF (https://freedomnode.com/blog/75/how-to-fix-slow-bitcoin-transactions-with-replace-by-fee) or pay $4 on confirmtx.com


If we use this transaction as an example, how do we take the data from
  this and format it into a RAW signed transaction that I could send
  straight into the network without the need of a wallet?

The referenced tx is already spent. So it cannot be re-used. Also you cannot reformat it into a RAW signed tx. There would be 2 steps required. First reformat into a "RAW UNSIGNED" tx, and then this would run through another set of commands to get it signed. Only then it could be sent to the network.
In the example, there is a bit of data missing, I'll add quickly. It becomes clear with the two links below:

version       01000000
Input(s):     1
Previous tx:  f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index:        0
script length 48
scriptSig:    304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
Sequence      00000000
Output:       1
Value:        5000000000
script length 19
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Locktime:     FFFFFFFF

now you have chosen a coinbase tx as reference, which adds some more difficulty, but ignoring this, then next step would be serialization. Instead of repeating, here are links to  amaclin's work or runek's work.

  Also, after creating the signed RAW transaction, is it just hashed by
  SHA256 to create its hash ID or does creating the ID consist of other
  steps?

No. Not that easy :-) See the link above, and what also gave me a very good hint was Ken Shirriff's blog "Bitcoins the hard way". There is many different data representation involved, including reversed hex and more, which adds layer(s) of complexity.

  Lastly, what is scriptSig? I don't quiet understand scripts in general

Basically it makes sure, that the condition to spend the transaction's funds are verified. This has been asked several times in bitcoin.SE, so I provide another link (see my answer further down):
Why does Bitcoin uses a Script language?

And as said in this link, the book from Andreas answers all these questions very well. Really highly recommended.


How can I determine how much "gains" I've had from Bitcoin?

It may be a bit of work, but you should be able to trace on a blockchain explorer (eg blockstream.info) when you acquired the bitcoin with the current addresses you have.
If you can't prove how much you paid for it with a record for each purchase, your tax jurisdiction may accept a historic exchange rate from a well known and reputable public exchange at that time. I suggest asking your government if that is a possibility first, before reporting that you received the coins for free.
To calculate your gains from your purchases and sales, different accounting methods exist (FIFO, LIFO, WAC, etc). If your government is not clear on which method they accept or don't know how to do that, you may need to contact a local tax advisor to help you out further.


There are no "owners" of bitcoin. It is like a protocol or algorithm, such as HTTP or SHA256. No one made money creating the program; it's free and open source!

However, there are people who make money by "mining". From the bitcoin wikipedia page:

  Bitcoins are awarded to Bitcoin "miners" for the solution to a difficult proof-of-work problem which confirms transactions and prevents double-spending.

Miners can also get extra bitcoins from voluntary transaction fees. In every transaction, it is recommended to pay a tiny fee so that miners will have an incentive to actually compute your transactions in the next block. Without a miner to verify your transactions, there is no way you or your payee can ensure that the bitcoins transferred are valid.


What methods are available to search for “lost or abandoned “ bitcoin?

There are no methods available to other people (third parties). People could search for dormant amounts that were outputs of old transactions and not yet used as inputs to subsequent transactions - but those amounts may not actually be lost or abandoned. There is no way to recover control or gain control of these amounts without additional information known only to the person who received those amounts of bitcoin.

If you previously received some amount of bitcoin into a bitcoin wallet, you can search for evidence - perhaps a note of an online website who stored that amount on your behalf and who you could now contact for assistance. Perhaps some old "wallet.dat" files on a PC that indicate you had a desktop wallet with control of your own private keys. Maybe an app on an old phone in a drawer. Perhaps a written down recovery seed or private key in a locked box you use for important documents.


Unexpected behaviour Bitcoin RPC getbalance

NULL and an empty string are interpreted differently. An empty string has no values. It’s an empty char array, one that hasn’t been assigned any elements. The string exists in memory, so it’s not NULL. Therefore we have two different labels and two different balances associated with those labels.


Multibit 0.5.14 is a MultiBit classic version which does not have seed words and does not support Hierarchical Deterministic wallets. So long as you know the password to your wallet and you have an up to date backup of it, you will be able to access your Bitcoin. There are no seed words for you to recover.

However, MultiBit 0.5.14 is an extremely old version of MultiBit. It is a version of MultiBit classic which was deprecated and replaced with MultiBit HD (which has seed words). Furthermore, MultiBit HD is no longer maintained and supported. So your version of MultiBit is several years out of date, contains potential vulnerabilities, and is no longer maintained whatsoever. I would highly advise that you switch to using a different wallet software such as Electrum.


Is there A Mechanism In Place that Prevent Address 'Squatting'?

The network doesn't require proven ownership to make an address valid, otherwise one would never be able to send bitcoins to a new address. Any address in the address space can receive a transaction at any time. Also see here:
At what point is a new wallet known by the Bitcoin network?

Creating a great number of addresses is possible, but impractical, because the address space is simply too big for anyone to even store a significant portion of the addresses. See a more thorough explanation here:
Is it possible to brute force bitcoin address creation in order to steal money?

Assuming the "That distributed DB" refers to the Blockchain, the Blockchain stores every transaction ever made on the Bitcoin network. See What is the “blockchain”? and Where are the user's bitcoins actually stored?.


How do I store coins during the bitcoin segwit2x hard fork?

It doesn't matter. Both types of addresses are safe during the hardfork, and you'll have access to both coins.

Have a nice weekend.


I think I have an answer. It's not clear if this is how blockchain.info does it, but I'm not sure it matters, either.

Taint is very similar to the everyday experience of diluting a liquid.

Imagine starting with three glasses. One glass contains orange juice. The second contains water. The third is empty.

Pouring some or all of the orange juice into the empty glass doesn't dilute it at all. However, pouring a 1:1 mixture of orange juice and water into the empty glass dilutes the orange juice.

We can define a metric called dilution factor. Dilution factor equals the final volume contained in the formerly empty glass divided by the volume of orange juice added. The dilution factor for a 1:1 mixture is therefore 2 (2 / 1). If no dilution takes place, then the dilution factor is 1. More generally:

dilution factor = V2 / V1 if V2 > V1

dilution factor = 1 if V2 <= V1

We can add another empty glass and dilute again. For example, we can take half of the diluted orange juice and dilute it with an equal volume of water. This gives a second dilution factor of 2.

The overall dilution factor equals the cumulative product of the dilution factor at each step. In this case, it is 4 (2 x 2).

Now imagine that monetary value is like a liquid, and an output is like a container. We can do dilution analysis just like we did with orange juice.

In this case, the dilution factor tells us how diluted the value of an output in a chain of ownership has become relative to a downstream output. Provided that the limits of this metric are clear, it can be useful.

The liquid being diluted is "taint". In this model, "taint" would be the multiplicative inverse of dilution factor. A dilution factor of 2 implies a taint of 50% (1/2).

Returning to the question posed above, given this chain of ownership, find the dilution factor between A5 and A4:

A5(5 BTC)->A1(2 BTC)->A3(3 BTC)->A4(4 BTC)

The dilution factors are, from left to right: 1; 3/2; 4/3. Multiplying them together gives 1 x 3/2 x 4/3, or 2. This is a 50% taint, the same answer as I got above.

However, the answer postulated in my original question is wrong in that it doesn't account for serial dilution. Consider this chain of ownership:

A5(1 BTC)->A1(5 BTC)->A3(3 BTC)->A4(4 BTC)

The serial dilution factor is 5 x 1 x 4/3, or 20/3.

Simply dividing the final value by the minimum value upstream gives a dilution factor between A5 and A4 of 4/1.


Does LN require an on-chain "emergency lane" to mitigate systemic risks?

As far as I understand this is not needed. Let us assume we have an congested mempool and someone publishes an old channel state. This transaction will not be mined directly as the mempool is congested. The timelock during which this transaction can be revoked via the penalty mechanism is a relative one and starts as soon as the transaction is mined. So, this would happen once the fees are down again and then one can use the fees in their breach remedy transaction.

That being said, on-chain fees are a challenge for lightning. While a collaborative channel close can take the current state of the mempool into consideration and adjust the fees so that the channel closes quickly the case of of a unilateral close is much more difficult. When negotiating a new channel state, we don't know what the fees will be in the future. So, when force closing we might have over or underpaid but we can't change the fees anymore since this would require a signature from the unresponsive party.


Think of a blockchain-based implementation of the financial backbone as the modern-day equivalent of Automated Clearing House (ACH), the national standard for processing checks.

Based on banking documents and blockchain organizations focusing on blockchain-based solutions for the commercial banking sector the solution will be a permission-ed, national-level blockchain with each participating bank being allowed access to the network. In this affect each bank would also be a miner with no reward, just confirming the transactions are valid.

The matter of confidentiality will be determined by the customers, and will pick their method of banking accordingly.


Is blockchain.com the only place where you can see the blockchain?

Blockchain.com is a wallet service and provides a "blockchain explorer". The company is named after the Bitcoin network's transaction journal, the blockchain.
Bitcoin is a permissionless peer-to-peer network. Users interact with the network by running software that implements the Bitcoin protocol.
There are various types of software that interact with the network to different degrees, but the backbone of the network are the so called "fully validating nodes" or fullnodes. Fullnodes distinguish themselves by downloading and verifying the complete blockchain. Archival nodes maintain a complete copy of the blockchain, while pruning nodes discard the oldest parts of the blockchain data after using it to calculate the current ledger. New nodes joining the network download the blockchain data from existing nodes.
Most Bitcoin software does not download, verify and store the complete blockchain. These "thin-clients" rely on other nodes or central services to serve data about the Bitcoin network's state to them. Wallet software (such as e.g. the Blockchain wallet) usually belongs to this category of node.
So, to answer your other question: your computer only stores the blockchain if you run a fullnode, e.g. Bitcoin Core. Then you can "see" the blockchain by requesting data from the fullnode. There are various projects that bundle visualization or blockexplorer software with the fullnode, to make the "seeing" part a bit more user friendly. ;)


What is the maximum size of a DER encoded ECDSA signature?

A signature in Bitcoin (as used to sign transactions inside scriptSigs and scriptWitnesses), consists of a DER encoding of an ECDSA signature, plus a sighash type byte.

Overall, this means they consist of:

DER encoded signature data, consisting of:

1-byte type 0x30 "Compound object" (the tuple of (R,S) values)
1-byte length of the compound object
The signature's R value, consisting of:

1-byte type 0x02 "Integer"
1-byte length of the integer
variable-length R value's bytes

The signature's S value, consisting of:

1-byte type 0x02 "Integer"
1-byte length of the integer
variable-length S value's bytes

The sighash type byte

Summing this all up, we have 7 bytes (compound header, compound length, R value header, R value length, S value header, S value length, sighash type byte) excluding the actual R and S data bytes.

So we have reduced the question to wondering what the size of the R and S data bytes are. These encode 256-bit values, which ordinarily means 32 bytes. However, integers in DER are signed, which means that if their highest bit is set, they are interpreted as negative. For that reason, if the value being encoded is 2128, a 33rd byte is added in front.

There is a standardness rule on the network that requires the S value to be below N/2 (N being secp256k1 curve order) ("Low S"), but no such rule exists for R. Furthermore, it is only a standardness rule which miners are allowed to bypass.

So ignoring the Low S rule, signatures (including the sighash type byte) can be up to 7+33+33 = 73 bytes.

Perhaps the number you're citing also includes the push opcode used in scriptSig to push the signature onto the stack, but that still only gets us to 74.

Perhaps the 75th byte is the length of the scriptSig itself? But that would only be relevant for scriptSigs which consists of just a signature - for example P2PK spends.


binance on site data and api data doesnt match

I have realised that the site doesn't refresh correctly, and I only needed to reload the site to match the one that gets returned through the api


Unconfirmed transaction for 6 days now. Please help

You can probably use CPFP to add a massive fee and get it mined.  Essentially, you spend the unconfirmed transaction in another transaction (to yourself for example) and just use a really big fee.  Eventually a miner will want to mine both to get the fees.


I would like a wallet that lets me export my private keys

Try it with JAXX wallet, I think there you're getting your keys


Pegged transfer from private blockchain to sidechains - Issue

The secondScriptSig is a script in each transfer transaction which satisfies the chain-global secondScriptPubKey. The secondScriptPubKey is intended to allow, in a flexible way, each chain to define its own additional terms. For example, a chain may restrict transfers to only be allowed if they are co-signed by a multisig federation (in the full federated peg mode), or restrict the total value which may be pulled out of a sidechain in individual transfers. In alpha, it is effectively unused - hence the secondScriptSig simply being the constant script "OP_TRUE".


Verifing the given R/S pair (signature) against a hash using the public key

I suppose you use the BitCoinJ library.

You are not creating a signature the correct way; an ECDSASignature object should be initialized with the ECDSA signature parameters (r,s), not the actual private and public keys. The constructor you are using, implies that the ECDSA signature has been computed already, you somehow got r and s and you initiate the signature object.

To achieve your required functionality, use the doSign(Sha256Hash input, BigInteger privateKeyForSigning) method of your ECKey and the output will be your desired ECDSASignature object.

The input on doSign should be the same with the input on verify, which is always the SHA256 of your message to be signed. If you want to spend an P2PKH output you must sign the public key, check this post for more information.


How can I get the transaction history of a bitcoin address?

Is it possible to get that address's full transaction history (send/receive addresses and amount)

Yes, all that information is in the public blockchain.
type the address into any blockchain explorer

if the owner bought bit coins using a credit card will I be able to see that and possibly the card number

No. That information is not public. It isn't really part of Bitcoin - not the network protocol, the blockchain or the reference software.

who can see that credit card number?

The merchant involved may, or their payment processor. But this part of your question is absolutely nothing to do with Bitcoin.


What did Deepbit to make their inputs special on transactions?

Those transactions spend Pay-To-Pubkey outputs. These are not special or strange and are actually the very first kind of outputs to ever exist in Bitcoin. These outputs simply do not have an associated address type which is why block explorers do not show an address for them.

Also, just because a block explorer can't show an address type does not mean that Bitcoin Core can't parse it. Block explorers don't just use Bitcoin Core, and Bitcoin Core actually does not display addresses for inputs.


Is there a block explorer for Ardor Testnet?

The ardor portal block explorer also monitors the testnet, see https://test.ardorportal.org/monitor


Can bitcoin node startup be secure without validating the entire blockchain?

Full nodes serve several functions on the network:

Validating the blockchain on behalf of their owner
Supplying previous blocks and transactions to other nodes
Relaying transactions and blocks to other nodes

Not validating the blockchain independently sacrifices each of these functions to a degree.

If the node does not independently validate the blockchain, the owner of the full node is still relying on trusting the peer nodes
If the node does not store previous transactions and blocks, it cannot supply them to other nodes that are catching up with the network
If the node hasn't validated the blockchain, it could be tricked into relaying invalid transactions and blocks.

So yes, a node can skip the important step of downloading and validating the blockchain, but I don't think I would consider it to be a "full node" anymore.  It would not be helping the overall network health, nor could it be completely trusted by its owner.  At that point, I would suggest simply running an SPV node.


Is it possible to avoid a ~$40 fee for a 220-input transaction?

bitcoinfees.21.co shows that fees are fairly low currently. You may try to export keys from your old electrum wallet, and load them into a new Electrum wallet (then you don't need to "transfer"), and go from there. The newer version allows to set tx fees in Saoshi/Byte.
Alternativly:
If you are on OpenBSD, Linux or MAC, you could give it a try with these shell scripts: github.com/pebwindkraft/trx_cl_suite (you don't want to provide your private keys or similiar to anyone!).
I used the tools last recently to create manually a tx (c9908124e59a2794f3807b366be7d235ff7654251adcdf396e209236341b3c32) with 20 Satoshis per Byte, having a size of 18KBytes.


How does bitcoin find the block locator hashes in the leveldb database?

The answer is that it doesn't use LevelDB for this.
It has an in-memory data structure with all known block headers, each pointing back to its parent. It also has a vector with pointers to all block headers in the currently active chain.
To build locator objects, it simply looks in this vector at specific indexes.


How are we so sure that the bitcoin network is connected?

how do we ascertain that the bitcoin network [...] is one connected graph

Problems paying people.

The senders and recipients in transactions are people who make contact using non-bitcoin protocols - for example HTTP websites, SMTP email, chat, in-person, by phone.

Therefore if the Bitcoin network were fragmented we should expect that pretty soon a person whose wallet is in one fragment would experience difficulty paying someone whose wallet was in a different fragment.

This would occur because different fragments would have different head blocks in their blockchain and pretty soon miners in one fragment would not be able to process transactions whose inputs were from a block they don't have.

I would expect Bitcoin discussion fora would gradually become filled with the wailings and gnashings of a horde of frustrated, angry and bewildered Bitcoin users.

I mean, more than the fora normally are :-)

After this became known, I would expect at least one or two whales to succumb to the temptation to double-spend massively. If so it seems superficially it would be a huge crisis for Bitcoin.

In practice, since this has not happened yet, I guess it would take some massive splitting of the Internet (e.g. Putin turns on his Russian Internet isolation switch for sufficiently long).

When there is a hard-fork (e.g. BCH) something a little similar happens, people who own n BTC before the split now own n BTC + n BCH. In the case of Bitcoin network fragmentation, someone who owned n BTC before would now own n BTC in fragment A and n BTC in fragment B. Although this might make them happy, potential recipients would worry about the consequences in an eventual remerger of those fragments.


How can a non-miner store data in the block?

There is a service named btcmsg which allows you to do this. Here is the announcement in bitcointalk. The website is at btcmsg.staticloud.com.

They use a simple protocol to write and read the messages in the blockchain:

  BTCmsg Protocol v1 (2011-09-18)

  Each message is represented by multiple payment which is calculated by
  the following algorithm:

  Two first chars for message type ('01' for md5, '02' for ascii).
  Then the message in hex (python binascii.hexlify).
  Split the long string to groups of 4 hex digits.
  Each group of 4 hex (e.g. 2 ascii letters from the message) is     represented by a payment in satoshi (maximum 0xffff=65535).
  The service fee (composed of a fixed part and a variable part times     the amount of small payments required, minus the transaction fee) can be seen within the first transaction.


Would replace by fee increase the fee on my transaction?

You can only increase the fee with BIP125 (opt in replace by fee) if your original transaction did already signal that it can be replaced.

If you made your transaction with Bitcoin Core 0.12, your transaction doesn't signal replicability.

Since Bitcoin Core 0.14 there is a global option called -walletrbf that makes sure, all your transactions do signal replaceability.

What you can do in your case is...

CPFP (child-pays-for-parent).You can try to create a follow-up transaction with your change output of your original transaction that hasn't confirmed. The follow-up transaction should have a high fee. If a miner wants to mine your follow-up transaction with high fees, he must also pick your original transaction (an unconfirmed transaction chain).
If it doesn't confirm, try abandoning the transaction (since Core 0.13) and re-spend your input
Try to use -zapwallettxns (google)