Why Ardor does not use Maven? Are there some reasons why maven and standard maven directory layout are not used in Ardor?

There are several reasons for this:

We don't want a dependency management tool to automatically download software from the web. There is always a risk of some backdoor inserted by someone malicious in case we do not manually verify each 3rd party component.
We would like to keep the build scripts as simple and low level as possible to maintain full control of the build output. Specifically, we would like to make sure the build is 100% reproducible from source so that anyone can rebuild it to make sure the published source code is the one used to build the published binaries.
We don't particularly like Maven.


ECDSA Input When Transferring Bitcoin From Owner A to Owner B I want to get my terms right and master how transactions work within the Bitcoin network.

Keeping things simple, when Alice wants to transfer 1 BTC to Bob, Alice signs a message with her private key. That message is passed to an ECDSA encoding function and prepared as a Sig. Alice also has Bob's public address.

I think what happens is that a transaction (record?--can it be called that?) is prepared that consists of a back-link to Alice's Tx ID, the recipient (Bob's) Public Key, Input/Outputs for the coin, and possibly other data. A hash of all of the data for Bob's transaction record is used as the new Tx ID. This record then floats around as an unconfirmed transaction in the transaction pool.

Upon verification, the Sig in Bob's unconfirmed transaction is validated with Alice's Public Key by passing the unconfirmed transaction's Sig, message, and Alice's public key to a ECDSA verification algorithm and examining the true/false result (true meaning that the message indeed was signed by Alice).

My Questions (all brief answers, I think):

0) Is it okay to refer to the data structure for a transaction as a "transaction record"?

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?

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

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?

Thank you.

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.


Ledger Nano Mnemonic Generation and Questions From the ledger documentaion we have

The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element.
The first 8 bits of the SHA-256 hash of the initial 256 bits is appended to the end, giving us 264 bits.
All 264 bits are split into 24 groups of 11 bits.
Each group of 11 bits is interpreted as a number in the range 0 - 2047, which serves as an index to the BIP 39 wordlist, giving us 24
words.

The result of this process is that your device will generate a single
mnemonic seed out of 2^256 possible mnemonic seeds (That’s one of 115
792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564
039 457 584 007 913 129 639 936 possible mnemonic seeds). Note that
while the first 23 words are completely random, the final word was
derived from 3 random bits and 8 calculated bits from the SHA-256
hash. This means that the final word can act like a checksum - if you
input an incorrect seed into the device while recovering it, it is
possible for the device to detect that the inputted seed is invalid.

What was the motivation to move 8 bits to the end and use 2^11 possible words instead of move no bits and use 2^8 words with a 32 word mnemonic resulting in a bijective correspondance between the set of permutations of words and the set of possible 256 bit sequences.
Because of the dependence of the last word on the first 8 bits, there are (2048)^24 - 2^256 \approx 2.95 x 10^79 invalid 24 word mnemonics. Does anyone know what would happen if you tried to input on of these into a ledger during recovery mode? Mathematically it should give a random 264 bit sequence and then either 1) check that the first and last 8 bits are the same - if not, error. 2) throw the last 8 bits away to obtain a valid 256 bit seed that would correspond to a different mnemonic, where the # corresponding to the 24th word began with the same 3 digits.
"The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element." This is the only part that startles me a little. I feel like I remember reading in the past that a lot of attacks happen because random number generators can be exploited because they are not truly random. How is the randomness of this TRNG tested?

What was the motivation to move 8 bits to the end and use 2^11 possible words instead of move no bits and use 2^8 words with a 32 word mnemonic resulting in a bijective correspondance between the set of permutations of words and the set of possible 256 bit sequences.

Typical word lists are 2048 entries, and that seems to be well established as usable. Using 256-entry lists would mean significantly longer seed phrases, which are presumably less optimal in terms of convenience. Deviating from that just so that the bits align with 256 would seem very strange.

Because of the dependence of the last word on the first 8 bits, there are (2048)^24 - 2^256 \approx 2.95 x 10^79 invalid 24 word mnemonics. Does anyone know what would happen if you tried to input on of these into a ledger during recovery mode? Mathematically it should give a random 264 bit sequence and then either 1) check that the first and last 8 bits are the same - if not, error. 2) throw the last 8 bits away to obtain a valid 256 bit seed that would correspond to a different mnemonic, where the # corresponding to the 24th word began with the same 3 digits.

The text you quoted says the 8 checksum bits at the end are computed using SHA256 of the 256 entropy bits; not just a copy of the first 8 bits.
I don't actually know what happens if you enter a seed with mismatching checksum, but I suspect the device will just reject it.

"The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element." This is the only part that startles me a little. I feel like I remember reading in the past that a lot of attacks happen because random number generators can be exploited because they are not truly random. How is the randomness of this TRNG tested?

Randomness is indeed hard, but you buy a hardware wallet because you trust its security more than you trust a software wallet running on general purpose hardware. If that's not true for the RNG in it, don't use it - you can always generate it elsewhere and import.


What is the absolute minimum amount of information required to have access to a bitcoin balance and or a wallet file? As far as I gather a wallet can remain offline indefinitely transactions are being sent to it. The network will keep track of the transaction so that the next time it is connected it will catch up.

Is the entire wallet file necessary for this process? is it possible in theory to strip it down at all and recreate from even less than a minimal wallet file?

I would essentially like to know what is the minimum theoretical data footprint required to obtain access to balance. The motivation behind my question is that many long term archival data formats are not very dense. Like stone etchings for example

Nmat answer is correct the absolute minimum you would need to rebuild a wallet is the private key of the address.

An alternative is a deterministic wallet.

What is a deterministic wallet?

A deterministic wallet can use cryptographic algorithms to create (and recreate) and wallet containing multiple public/private keys from a single passphrase.

A deterministic wallet has the advantage of being able to create an infinite number of addresses from a single passphrase.

A deterministic wallet has the disadvantage that if the passphrase is retained but the software & algorithm is lost then the addresses can never be recreated and all value lost.

That risk could be partially mitigated by keeping multiple copies of the wallet generation software both online and offline.  As a final backup the algorithm (and optionally  the passphrase) could be etched or cut into a thin sheet of aluminum (8.5" x 11" to simplify storage) using a laser cutter.  This would provide a time resistant disaster recovery method.  Using a sheet with dimensions of standard documents would allow it to be easily stored in a safe or safety deposit box.  This task is simplified because many cryptographic algorithms can be expressed using diagrams which reduces the amount of space necessary to express the algorithm.

For example SHA-256 (and SHA-512) can be partially expressed by this diagram:

To completely express the algorithm you also need to record each variable, the number of rounds, and the meaning of the symbol operators.


Why is it so hard for alt clients to implement Bitcoin Core consensus rules? I understand that one can never be certain that an alt Bitcoin client is fully in consensus, but what is it about the consensus rules that makes them so hard to implement in other clients?

Because they're not known.

This may sound surprising, but you have to realize that Bitcoin's consensus rules are defined by what (economically relevant) full nodes actually enforce. We can assume at this point that that is mostly various versions of Bitcoin Core, and derived projects, but that may change over time.

However, they are certainly not defined by some document that people blessed into being the rules. Even if we would somehow create such a document, and everyone would agree to it, what would happen if we realized that there was a bug in actual implementations? In that case, you could call the implementation buggy, but you can't just change it. Any (uncoordinated) change to implementations could result in them ending up in their own fork, resulting in all preexisting coins being spendable twice on each side (the precise thing the blockchain was designed to prevent). Thus, in such a situation there would be no choice but to change the document. Essentially, Bitcoin's consensus rules can be described, but not prescribed.

All of the above is to illustrate that it is not sufficient to replicate any specific intended behaviour; you must mimick the exact behaviour of existing software. You must:

Accept every valid block, but you also reject every edge case exactly that causes rejection.
Guarantee that nodes can find each other
Guarantee that nodes continue to download blocks from each other in various circumstances
Prevent transitive disconnects/bans (A should not be able to relay a block to B - which possibly runs different software - in such a way that when B relays it to C, C disconnects or bans B).
Take performance considerations into account. If a block or transaction can be constructed that a significant amount of time to validate, you simplify selfish mining attacks. If validation time can be caused to take close to the block interval time (10 minutes), convergence across the network may fail entirely.

Even worse, all of these properties must be maintained under adversarial circumstances. Blocks may not only contain randomly stumbled-upon edge cases; people may actively try to trigger them.

Mimicking the behaviour of software exactly is a very hard problem. While there is some progress in the field of provably correct software (which includes proving equivalence between two programs), it is nowhere near advanced enough to apply to something like Bitcoin's consensus rules. As a result, the only approach for replication is reimplementing the rules as you believe they are implemented already, without strong methods to guarantee you're right.

In short, in order to replicate the behaviour, you must know the existing behaviour. And history has shown that in many cases, the existing behaviour is not exactly known:

The OP_CHECKMULTISIG redundant stack pop. This one has been known for a long time, but it probably was not known in the first months or even years of Bitcoin's history. The OP_CHECKMULTISIG opcode pops one more element off the stack than needed. People have worked around it by pushing an extra OP_0 when spending a multisig output. BIP 147 has been proposed to require that to be an OP_0 even. In Bitcoin's early days, a reimplementer would likely have incorrectly replicated this.
Compressed and hybrid public keys. According to various specifications, secp256k1 public keys can be encoded in uncompressed, compressed or hybrid formats. Bitcoin initially only used uncompressed keys (comments in the source code indicate that the original author of the software was not aware of compressed keys), but as every node at the time was using OpenSSL for validation, people were able to just start using compressed keys and the network accepted them. In this case, an unknown part of the rules was 'abused' for an improvement.
OP_SIZE does not pop the stack. All opcodes that inspect a stack element also pop that element. There is one exception to this (OP_SIZE), which at least one reimplementation got wrong.
The distinction between signature validation failure and script execution failure. Some reimplementations have initially treated signature failures as script failures (which is a correct assumption for almost all scripts, but not all). Consider a script of the form <pubkey> OP_CHECKSIG OP_NOT. This is a script that consumes one signature from the stack, and requires it to a signature that is invalid in order to pass.
Serialized size vs. normative size. Various resource limitations exists on the size of blocks, transactions, scripts, ... However, these sizes are defined in terms of the number of bytes that would be produced by serializing the data structure. Sometimes, multiple valid serializations used to exist. At least one reimplementation for period of time used the size of a block - as sent on the wire - to check against the block size limit. However, a 999999 byte block could have been sent using a longer-than-necessary serialization of the number of transactions in it, resulting in perhaps 1000001 bytes. This is a valid block, but the reimplementation would reject it.
OpenSSL's inconsistent DER parser. OpenSSL used to support signatures encoded using various deviations from the DER standard, often with arbitrary restrictions and weird differences (an integer could be encoded as a struct containing an integer), implemented in thousands of lines of hard to read C code. At the time, every reimplementation that did not use OpenSSL could have been trivially forked off by creating a transaction that abused on of those weird deviations. This is a very good example, as it is likely that nobody ever exactly knew what OpenSSL accepted and didn't. This was eventually fixed by BIP66 which made signature parsing much more restrictive, and allowed us to move away from OpenSSL after it became a network rule.
OpenSSL signature parser inconsistency. The OpenSSL signature parsing story goes further: it was discovered that one of its permitted DER deviations was platform dependent. A particular length descriptor was allowed to be up to 4 bytes on 32-bit systems and 64-bit Windows, and up to 8 bytes on others. This resulted in Bitcoin Core instances on different platforms to be inconsistent with each other even, much less be consistent with reimplementations at the time. This discovery was indirectly fixed by BIP66 as well, by requiring that the shortest possible length descriptor had to be used. The full timeline is in this disclosure.
The BDB lock limit. Early versions of Bitcoin Core (before it was called that way), up to version 0.7.x, used a chainstate database implemented in BDB. BDB is a multi-process database environment (something we don't need) that needs a preallocated number of locks to prevent concurrent access to records and deadlock detection. Turns out that the number of locks chosen was mostly enough for processing Bitcoin blocks, until one unfortunate block on March 11th 2013. This was a block with a remarkably large number of inputs (and few outputs), resulting in way more transaction records in the database model of that time being affected. The preconfigured number of locks was exceeded, the database operation failed, and Bitcoin was unable to process that block. As a result, a fork appeared. It was compounded by the fact that many miners had already upgraded to version 0.8.0 (which used LevelDB and no longer had this lock limitation), while many other nodes had not. More information can be found in the post mortem document BIP50.
... Who knows which things we don't know about yet?


How to change the data directory with bitcoin-cli? I am trying to change the data directory used by bitcoind and I am uder the impression that the command -datadir was removed as I can't find it with bitcoin-cli help, when I try to use it I get Too few parameters and bitcoin-cli help datadir says datadir doesn't exist. I need to specify a directory that is not on the root partition, how to do it ?

Also why bitcoin core is so user unfriendly, it's quite surprising I thought it was the main bitcoin program. It started downloading the blockchain on my root partition without me even being aware of it (just start bitcoind and it starts silently downloading).

you should use it like this bitcoin

bitcoind -datadir=/your/external/path

Hope this helps!


Can I buy bitcoins with moneygram in Australia? I notice you can do it like this in the U.S http://vimeo.com/44849463 but is the same method possible in Australia? We do have moneygram at 7-11's here.

You can just use one of the bank exchanges such as omnicoins or bitXoin for this function. There are less fees as well.


how to config p2pool so that it can connect to bitcoind wiht HTTPS? Now I have installed bitcoin with config rpcssl=1, and I have tested the connection with a java application. Everything seemed OK.

Then I installed p2pool, and tried to connect to bitcoind (python2.7 run_p2pool.py), and I was faced with the following errors:

Testing bitcoind RPC connection to 'http://127.0.0.X:8332/' with username 'pool'...
2014-07-16 15:29:25.036426 > Error while checking Bitcoin connection:
2014-07-16 15:29:25.036567 > Traceback (most recent call last):
2014-07-16 15:29:25.036770 > Failure: twisted.internet.error.ConnectionDone: Connection was closed cleanly.

Then I modified the bitcoin.conf and erased the rpcssl=1 item, restarted bitcoind. Then I run the command, connecting to bitcoind successfully.

So I wonder how to config p2pool so that it can connect to bitcoind with HTTPS?

For using SSL with Bitcoin follow these instructions: https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon

Maybe your RPC Connection String have connection type "HTTP"

connection-type = "http"

Change http to https


What does the 'n' in nLockTime and nSequence stand for? I know what nLockTime and nSequence do, but I'm just curious about where the 'n' comes from. Thanks

It stand for a number, it is commonly used in programming to designate a variable that gonna hold an amount of something see: https://en.bitcoin.it/wiki/NLockTime and https://en.bitcoinwiki.org/wiki/NSequence


New Numbers: How many Bitcoin addresses are/have been carrying a balance? Same question as this: How many Bitcoin addresses are/have been carrying a balance?

However the answer there is from 2012. Anybody have the new numbers for reference?

Though, I don't have the exact number, an approximate number can be inferred from the number of unspent transaction output set or UTXO.

Each address with non zero balance will have an entry in UTXO. These days wallet create new address for each payment, so commonly addresses have one txout. However, most people reuse addresses and are used for donation, go through mixers etc and they end up with multiple UTXO.

Taking an approximate number of 2 UTXO per address.  This factor approximately matches with the number of addresses calculated in 2012 and the UTXO values for 2012 in the blockchain.info chart

For 2017, looking up from blockchain.info UTXO chart gives

47.3 million /2  ~ 23.6 million address


How to start programming using Ethereum? I'd like to listen opinions of people that have created already their own working contract. What have you read at the beginning and then? What was the most powerful source that helped you understand Ethereum generally and then deeper?

Full Documentation of Ethereum "Frontier":

http://ethereum.gitbooks.io/frontier-guide/content/

Discussion Forum:

http://forum.ethereum.org


How to use BlockChain API? I am a complete noob to PHP. But I just wanted to know how can you use the BlockChain API to get your wallet balance. I tried but could get no result. I do not even know how to print it. Please help. This is my current code :-

    <?php

    $guid="xxxxxxxxx";
    $main_password="xxxxxxxxx";

    $json_url = "https://blockchain.info/merchant/$guid/balance?password=$main_password";

    $json_data = file_get_contents($json_url);

    $json_feed = json_decode($json_data);

    $message = $json_feed->message;

    ?>

And what exactly is the guid? Is it the wallet identifier?

Your code is close to what you need:

<?php

$guid="xxxxxxxxx";
$main_password="xxxxxxxxx";

$json_url = "https://blockchain.info/merchant/$guid/balance?password=$main_password";

$json_data = file_get_contents($json_url);

$json_feed = json_decode($json_data);

$balance = $json_feed->balance;

echo $balance;
?>

The response looks like this (Wallet Balance in Satoshi):

{ "balance": 1000}

So you need to fetch the balance object not the message one.
Then add an echo to print out the balance.


nSequence doesn't block my transaction I'm studying how Timelock works.
I'm able to create transaction with absolute time, nLocktime and OP_CLTV. Now I want to understand the relative part, and I start with nSequence.

At the moment I use createrawtransaction to create my raw transaction, where

bitcoin-cli createrawtransaction '[{"txid":"'$TXID'","vout":'$VOUT',"sequence":'$TIME'}]' '[{"'$ADDR_DEST'":'$AMOUNT'}]'

Where $TIME is:

$ gdate --date 'now + 512 seconds' +%s
1589189045

Human Readable: Mon May 11 11:08:44 CEST 2020

I mined some blocks and my median time is Mon May 11 11:13:05 CEST 2020, When I try to send my Transaction I get this error:

error code: -26
error message:
non-BIP68-final (code 64)

Here my raw transaction

020000000001012d343a729ac2addc97ebdfd6e086b4c31060546b51134f208360fb2e3989c9cc00000000001c16b95e016036f829010000001600147163053fa92512e2fb2004e9173e564bbdeb8ed40247304402203cd801bc04a71e14b08445357a2f542758cc0cf32f573a6e5489109bfa31a5b90220429c3aa40e670d1fdfee5e8f910604a3c9aa7e656e886dd8ba2591e6f22787440121037bc7eb8a954817f1b95f55f79b0927c7f42f71d461da845c08b0858d125df23400000000

  {
  "txid": "f6cb3d437858ea1ddd81d45c1b391d27faf1b594e65d7f0ae312fc55f67aff12",
  "hash": "b833a701caaba372cdd87e01c08c18755d40bd9fc20568571f2d45be3d219781",
  "version": 2,
  "size": 191,
  "vsize": 110,
  "weight": 437,
  "locktime": 0,
  "vin": [
    {
      "txid": "ccc989392efb6083204f13516b546010c3b486e0d6dfeb97dcadc29a723a342d",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402203cd801bc04a71e14b08445357a2f542758cc0cf32f573a6e5489109bfa31a5b90220429c3aa40e670d1fdfee5e8f910604a3c9aa7e656e886dd8ba2591e6f227874401",
        "037bc7eb8a954817f1b95f55f79b0927c7f42f71d461da845c08b0858d125df234"
      ],
      "sequence": 1589188124
    }
  ],
  "vout": [
    {
      "value": 49.991,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 7163053fa92512e2fb2004e9173e564bbdeb8ed4",
        "hex": "00147163053fa92512e2fb2004e9173e564bbdeb8ed4",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "bcrt1qw93s20afy5fw97eqqn53w0jkfw77hrk5vtmsdk"
        ]
      }
    }
  ]
}

The same logic works with nLocktime.

See What does the sequence in a transaction input mean?

1) You need to set bit 22 in the nSequence to indicate the value is a timestamp, not a number of bocks.

2) You are trying to put an absolute timestamp into nSequence, but nSequence is used for relative time.

So if you want the relative timelock to be 512 seconds, your nSequence should be:

1 |= (1 << 22)

or 4194305


How do coloured coins work? From what I can gather coloured coins add some additional data to a UTXO, I'm trying to understand what mechanism us used to store the extra data and how the data is maintained in tact if the UTXO is sent to another party.
So let's say I have a 1 Satoshi UTXO, I can (somehow) write that it represents my car, registration number 123 ABC.
Now I transfer that 1 Satoshi to you as proof of transfer of ownership of what is now your car.  Does the data get destroyed at that time?
I assume for divisible items like bottles of wine, if I had 12 Satoshi in 1 UTXO, I could not send 1 Satoshi to you to transfer just 1 bottle?

An example from an explorer would be great, thanks.

Coloured coins work by making use of OP_RETURN.

I'll discuss the Omni Layer, which is currently the primary coloured coin implementation on Bitcoin.

Omni works by encoding additional data within an OP_RETURN.

Let's say I have a BTC address A, and hold 100 USDT in that address. Now, I want to transfer this USDT to B.

I will make a transaction from A to B with the following format:

Inputs:

Any BTC utxo for my address A

Outputs:

A small dust output to B <- This is used to identify the recipient of the coloured coin
An OP_RETURN that encodes the asset ID and amount <- This will identify that I am moving USDT, and 100 units of it
An optional change output that is larger than the dust limit <- any left over from my utxo.

If we look at this sample tx, the OP_RETURN value is 6f6d6e69000000000000001f00000000000003e8. In this, 6f6d6e69 is Hex for omni, identifying it as an omni layer tx. 1f is the asset ID for USDT, 31 in decimal. Finally, 03e8 is the amount, 0.00001 USDT.

Looking at the same tx on a regular explorer shows us the dust and change outputs as well.

Lastly, it is not important for omni layer transactions to spend a utxo from the same output that deposited the coloured coins to the address (i.e., you do not need to spend the dust when spending the USDT in the above tx). Omni uses a secondary accounting system maintained by the omni nodes, which simply tracks OP_RETURNs for balance calculations.

To prevent double spends, Omni will simply credit or debit accounts in the order transactions appear on the Bitcoin chain. If I attempt to transfer the 100 USDT from the first example to C in addition to B, it will get transferred to B or C depending on which tx appears first in the Bitcoin chain. The second tx, although successfully mined as it does not violate and bitcoin rules, will fail at an omni layer, and no coins will be transferred.


How does namecoin and other merge-mined coins prevent pre-mine attacks? So, namecoin supports merged mining against bitcoin. My understanding of the merged mining protocol is that basically miners can use the primary coin's POW solution to solve the aux coin's block. It's possible for a primary coin POW solution to not be difficult enough for the primary coin, but be valid for the secondary coin.

However, given this, what would stop a malicious person from working on forging a set of primary blocks, such that they would meet the aux difficulty. They would set their blocks up to be a very high height so they have plenty of time to mine the blocks at the target difficulty (since they don't have enough power to do it in realtime of course). And then, when they need to control of the blockchain, they would submit all of these forged blocks at the proper time, messing up target block times and allowing them to possibly double spend..

How is this prevented?

If you fake the bitcoin blocks, then you will be mining only namecoins and no bitcoins, so you are losing 99% of your mining income.

You can't just mine at a height above the current namecoin blockchain. Remember that it is a chain. Each block has to link to the previous one. If you want to mine at namecoin height X which is thousands of blocks above the current height, how will you know in advance what the hash of the block at height X-1 will be?


Bitcoin Testnet is not working I am new to Bitcoin Development Environment. Trying to setup testnet environment with the help this blog post.

Bitcoin Folder
~/.bitcoin $ ls
bitcoin.conf  chainstate  db.log     peers.dat
blocks        database    debug.log  wallet.dat

bitcoin.conf

telnet=1
server=1
rpcuser=userme
rpcpassword=mypassword
rpctimeout=30
rpcport=8332

Running Bitcoin

~/.bitcoin $ bitcoin-qt
"sni-qt/2440" WARN  16:37:44.104 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE

Where are you choosing testnet network?
In bitcoin.conf should it really be telnet=1?
Maybe you meant testnet=1?


Error trying to send payments with RPC sendmany Need help fixing this error.

Error trying to send payments with RPC sendmany {"code":-8,"message":"Invalid parameter, duplicated address

I a running a NOMP mining pool that has payment job breaking because there are two same wallet address payments in the same sendmany job. I need to limit amount sent to minimize chance of having the payment in the same transaction for a while until I get rid of this so that the payments go thru. Or, do something so that this is ignored.

I had this problem on a NOMP pool recently, I will share how we fixed it. For us, the problem was that a user had used the same address twice, but added some whitespace to their username the second time. So NOMP wouldn't recognize it as a duplicate, but the sendmany command would still fail. The solution for us was to do two things.

Eliminate the whitespace from workers' names. This commit shows how to do that.
Combine payouts together when there is more than one worker with the same address. The code for that is shown below.

In paymentProcessor.js, change

var address = worker.address = (worker.address || getProperAddress(w));
worker.sent = addressAmounts[address] = satoshisToCoins(toSend);

to

var address = worker.address = (worker.address || getProperAddress(w)).trim();
if (!worker.sent) {
    worker.sent = 0;
}
worker.sent += satoshisToCoins(toSend);
if (!(address in addressAmounts)) {
    addressAmounts[address] = 0;
}
addressAmounts[address] += satoshisToCoins(toSend);

If you want to know more about what caused this, the problem here is just what was explained in the error: there are duplicate addresses in the JSON object.

For example, I generated a new address of my own (1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy) and ran:

./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01, "1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'

And the error was:

Invalid parameter, duplicated address: 1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy (code -8)

To fix this problem, you either need to (1) add up all the amounts and pay to the address in one go, or (2) do separate RPC sendmany RPC calls, making sure to not have any duplicates.

In my case, (1) would look like:

./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.02}'

And (2) would look like:

./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'
./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'


Where can I find research on wallet fingerprinting? @raw_avocado asks on Twitter:

I remember reading at some point something about how you can identify
transactions made by specific wallets because they have a specific
fingerprint because of how they construct transactions.
Are there any public stats on this?

Where can we find more information on the unique fingerprints of wallets? Is there a website that tracks this information or maybe an academic paper?

Is this the research article you are thinking about? It's blockchain.com wallet fingerprinting mostly on the basis of feerates by 0xB10C.


Can multiple transactions transferring the same bitcoin be done in one block? For example, one bitcoin from address A to address B, then from address B to address C,

Assuming that prior to the transfer from address A to address B, no bitcoin had been sent to address B.

If the above is broadcast in the same block, would address C receive the bitcoin?

Yes, this is possible. This is seen happening today in MtGox's green address implementation. The two transactions are not guaranteed to be included in the same block, because the second transaction has a lower priority for miners to include it; but it's possible, and seems to happen in a lot of cases.

Quoting from MagicalTux:

  Actually if you look at : http://blockexplorer.com/address/1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q

  Look at transactions 597d00408b... and 557c87f205....

  597d00408b... is "A to B"
  557c87f205... is "B to C"

  Both happened in the same block, which is the expected behaviour.

  Previous tests did not always end in the same block, so I believe some miners may consider the second transaction lower priority as it involves not yet confirmed coins. In the case of those two transactions it was as fast as a normal transaction, but it cannot be guaranteed in 100% of the cases.

  If we look at the previous transactions we can see it was sometimes coming out with a difference of 1 block, or even more. If pools could put priority on green addresses it'd (mostly) solve this issue.

You can also pay a higher fee on the second transaction in order to compensate for the lower priority.


How does the pool know the share hashes are calculated and not cheated? Miners calculate share hashes and submit them to the pool for their proof of work. And if the share hashes leads to a correct block hash in terms of difficulty, everybody in the pool gets paid according to their submitted work using different distribution methods.

Question:
Why can't a miner just submit random numbers as fake share hashes (little work) to the pool, instead of doing the actual hard work of hashing?

So for the pool: Is there a way to prevent this without recalculating the hash to find out its fake? Recalculation is hard work, and annihilates the sense of delegating it to miners.

And if there is no control it would only be visible with statistics as the pool is too unlucky on the long term. Ex.: a miner submitting 100THash/s and never finding a match might doesn't even calculated the hashes but just submits random stuff.

Edit: Clarified question to distinguish from similar sounding questions.

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.


How is it possible to patch Bitcoin? How can someone patch Bitcoin?

I don't understand, if someone wants to change or add code to the Bitcoin repo. I've read there is a few people that have access to publish new code (?). Why are those people trusted? And how would they publish the new code so every node gets the updated version? Does every node download it from some central server? Or does someone push it? In both cases, it doesn't seem decentralized.

How can someone patch Bitcoin?

git clone
do changes
make && run

  Why are those people trusted?

You have a right not to trust them

  And how would they publish the new code so every node gets the updated
  version?

Node owners have a right not to upgrade to "referal" version

  Do every node download it from some central server?

No. Everyone have a right to change everything in his own copy of sources.

  Or do someone push it?

No.

  In both cases, it doesn't seem decentralized.

The development of "referal" software is not decentralized.


How does a hardware wallet interact with the bitcoin network? I tried to understand the principle how the hardware wallet sends transactions to another Bitcoin address since it is not connected via full node to the blockchain.
I found this answer: How do hardware wallets communicate with the outside world?
Do I understand it right that every hardware wallet company like Ledger, Trezor or Shiftcrypto run a full node (e.g. bitcoind) in their company network and every hardware wallet, which is connected via the locally installed company's software at the sender's computer just sends a request to this full node like this?
bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"

If so, do companies run it's own (closed source) full node which works in a different way? The only exception seems to be BitBoxBase from ShiftCrypto, which is open source.
But basically, the principle of the transaction handling between the hardware wallet and the blockchain is always the same, right? So every company run it's own full node. Only the transmission "protocol" between the hardware wallet and this full node is different and non-standardized, right?

No.
The hardware wallet company sometimes runs a node, but you could just as easily use a client like Electrum instead, and use Electrum nodes instead with your hardware wallet. All the node is used for is checking for transactions and publishing transactions.
The wallet software will use the xpub from the hardware wallet to check for payments people have sent to your addresses, using one of these remote full nodes.
Now, let's say you received some Bitcoin and you'd like to spend it. Your wallet software will generate an unsigned transaction on your computer, then it will send that unsigned transaction to your hardware wallet for it to sign, then the wallet software will use the full node to publish this signed transaction.
So like the answer you linked to pointed out, all the full nodes are used for is 1) querying for existing blockchain data, and 2) publishing (NOT creating) an already signed raw transaction.


transfer money to mtgox with visa or mastercoard I am looking into add funds tab from mtgox and I can not find an option with visa or mastercard.

E-Currencies:
Liberty Reserve (Instant funding - NO FEE)
PerfectMoney (INSTANT funding - 1% FEE)
Pecunix (INSTANT funding - NO FEE)
HD-Money (INSTANT funding - NO FEE)
VouchX Vouchers (INSTANT funding - NO FEE)
CosmicPay (INSTANT funding - NO FEE)
C-Gold (INSTANT funding - 5% FEE)
SolidTrustPay (WITHIN 1 to 2 business days - 8% FEE)

Banking and other payment methods:
SEPA Euro transfers (WITHIN 1 business day - NO FEE)
International Wire Transfer in USD (WITHIN 1 to 2 business days - NO FEE)
Wire Transfer in GBP (WITHIN 1 to 2 business days - NO FEE)
CASH deposit at 10,000 locations in the USA (WITHIN 1 hour - at 3.75% fee!)
INSTANT EURO BANK TRANSFERS (Coming soon!)
LOCAL AUSTRALIAN BANK DEPOSITS (Coming soon!)

Is it possible? If no, what is the easiest way to do this using MasterCard

Basically, you can't easily buy hard money (like Bitcoins) with soft money (like credit card payments). The problem is that customers could reverse or dispute the soft money payment and the trader couldn't get the hard money back. To cover their costs should this happen, they'd have to give lousy exchange rates.

These lousy exchange rates would chase away legitimate customers. But scammers wouldn't mind, they're not going to pay anything anyway. So the scam rate goes up, the fraud losses go up, the legitimate customers get chased away, and so on.

There do exist businesses doing this, but expect extensive credit checks, waiting periods, demands for detailed documents, and so on. Also, expect to pay too much.


Is there online tool to check if bitcoin transaction is bip-125-replaceable bitcoind json-rpc can do it, I think I saw this on blockchain.info but I don't see it now.

getmempoolentry does it. However this is restricted to txes currently in mempool.


Calculate tx fees before sending with sendtoaddress I see this question time and time again, but I only find answers for calculating the fees in creating raw transactions.

I am using sendtoaddress and would like to be able to calculate the tx fee needed prior to calling the api. I would like to avoid creating a raw transaction if reasonably possible.

how might i do this using the json-rpc api? (i'm using bitcoind)

If you call

bitcoin-cli settxfee <fee>

just before call

bitcoin-cli sendtoaddress "1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N" <value>

Then the fee will be <fee>.

Important note: make sure in the graphic mode (when you start with bitcoin-qt command) the "custom" is selected, otherwise your command settxfee will be ignored (see image bellow).

Also, I'm not sure if this option is selected by default, and I am not sure as well if it you can set "custom" via API. If someone knows that, please edit this answer and fix it.

Note 2: I'm not sure if this is strictly necessary, maybe not. I didn't make many tests. The test I made was starting bitcoin with bitcoin-qt -txindex -server & and then letting the interface open. If "recommended" is selected the command settxfee will be ignored. I didn't tested e.g. what if let the "recommended" option selected, close the interface and then start with bitcoind -txindex for example.


How does civic work? I have been doing a lot of reading up on bitcoin, but I can't find anything that explains how some technologies are used in conjunction with the blockchain.

From my understanding, the reason bitcoin is distributed is the blockchain is stored at multiple nodes (miners). When they validate transactions they get added to the blockchain and miners get a reward/transaction fee.

My current question is around civic. What would be the benefit to miners when it comes to a technology like civic (i.e. what would they mine and why)? What is the engine that keeps this data distributed?

Firstly, the 'engine' to keep civic decentralised is bitcoin itself. Its called PKI and anyone can generate as many private-public keypairs as required for free. These keypairs are already used for authentication in applications all around.

The simplest app one can think of is sign something and put it on the blockchain, just so someone knows you are alive. Civic is the app that does just that - helps you put data on blockchain and notifies any interested parties that your phone is still alive.

Secondly, there is no other part. Bitcoin is the 'engine', cypherpunks intended people to assemble the 'car' themselves. But in real-life some prefer to pay for the DIY instruction manual written in ELI5 manner or simply don't even know what they are buying.


What is the meaning and application of the apostrophes in derivation paths of BIP32 / BIP44? Can we please clarify if there is any difference (because apparently some technical documentation explicitly requests to include apostrophes) between a derivation from extended private key (xprv) or public key (xpub) of a child subkey, where m = root (xprv or xpub).

m/44/0/0/0 and  m/44'/0'/0'/0

What are the meaning of the apostrophes and how / when should they be applied? Do they change anything in a derivation path -- will the derived child subkey be different with or without them?

The apostrophes show whether or not that particular derivation is hardened.

The difference been hardened and non-hardened keys is described in BIP32.

See the wiki for some further detail. https://bitcoin.org/en/glossary/hardened-extended-key


Calculating the private key from a signature (r and s) requires that you know the message (to calculate the "z" value) and the "k" value (which is used by the signer to derive the r value via a trapdoor function).

Calculating the "k" value (needed above) requires two signatures (you need two s values) which sign two different messages (you need two z values) using the same private key and the same r (therefore the same k) value.

In your question, you reference two transactions signed by different private keys (which you know by noticing their public keys differ), and therefore you do not have enough information to correctly calculate the k value.

In the other similar question you recently asked, the two transactions were signed by the same private key (and they have the same r & k), so in that case it is possible to calculate the private key. (The service you linked to appears to calculate it correctly, however it doesn't display the uncompressed address.)


Read an XPUB list of transactions to Python using my own node Anyone familiar with a Python library that can get a list of all transactions under an XPUB but by connecting to a Bitcoin node through RPC?

Something like this might be a lead for what you're after.  It gives you a list of addresses which you can then query your node by RPC.

You then use the getbalance RPC method.  People I know use the python slickrpc package from pypi.


Any data immediately written to the blockchain when opening a lightning channel? When opening a lightning channel, is there any data immediately written to the blockchain?
I mean, the channel is not considered opened until the data is on the blockchain.
The data may be the funding transaction, or may be some sort of 2-to-2 multisignature script, I don't know.

If the answer is yes, then... is it possible that an opened channel becomes invalid due to a blockchain fork, i.e., the blockchain where the data reside being replaced by a longer,conflicting blockchain?

If the answer is further yes, then, is it possible that some sort of double-spending attacks can be launched on the lightning network?

When opening a lightning channel, is there any data immediately written to the blockchain? I mean, the channel is not considered opened until the data is on the blockchain. The data may be the funding transaction, or may be some sort of 2-to-2 multisignature script, I don't know.

The channel has a funding transaction which must be included in the blockchain before the channel is considered to be opened. Of course, you can use it before it is confirmed, but there is no guarantee of anything that happens in the channel.

  If the answer is yes, then... is it possible that an opened channel becomes invalid due to a blockchain fork, i.e., the blockchain where the data reside being replaced by a longer,conflicting blockchain?

Yes, that is possible. However it is extremely unlikely. Like with other transactions, nodes won't consider the funding transaction to actually be complete until it has several confirmations (usually 6). The probability that a fork of length 6 occurs is extremely low. Note that the risk of a fork here is the same as a fork effecting your normal Bitcoin transactions.

  If the answer is further yes, then, is it possible that some sort of double-spending attacks can be launched on the lightning network?

The same double spending attacks and risks that you can do to a normal Bitcoin transaction also effect the Lightning Network funding transactions because it really is just a normal Bitcoin transaction.


NBitcoin -- How do I just check the balance of my wallet from my seed phrase? I've looked through the docs, I've Googled, I've searched here, and it all just seems like Greek to me... I must not be using the right keywords, because I just can't figure out what I think should be the most dead-simple thing...
How can I use NBitcoin to open my wallet from my 12 word seed phrase and look at the balance? I feel like if I can just get some help getting that far, I can probably go from there to do more...
Also, does NBitcoin have an API reference guide?
Thanks all!

Use var key = mnemoObj.DeriveExtKey(); then you can derive addresses as explained in this chapter (https://programmingblockchain.gitbook.io/programmingblockchain/key_generation).
mnemo = new Mnemonic("minute put grant neglect anxiety case globe win famous correct turn link",
                Wordlist.English);
hdRoot = mnemo.DeriveExtKey("my password");


how can I create a block chain? How can I reate a block chain and a bitcoin wallet as I want to start trading in bitcoins.  I have never opened a bitcoin waller or block chain and am not sure if I should have both?

A blockchain is the basic data structure used to record the transactions in the network. It already exists, you don't need to create it. This is like asking "I want to send an email, how do I create an internet?".

You need Bitcoin wallet software. See https://bitcoin.org/en/getting-started for more information.


Prioritizing BTC transactions using Bitcore APIs I’m planning to give a feature in my application where a user can select type of priority (Fast, Average or Slow) for their transactions.

How can I get fee required for each type? Does Bitcore API provides any feature that handles priority of transactions?

This feature available on bitcoin-core RPC

bitcoin-cli help estimatesmartfee

estimatesmartfee conf_target ("estimate_mode")

Estimates the approximate fee per kilobyte needed for a transaction to begin
confirmation within conf_target blocks if possible and return the number of blocks
for which the estimate is valid. Uses virtual transaction size as defined
in BIP 141 (witness data is discounted).

Arguments:
1. conf_target     (numeric) Confirmation target in blocks (1 - 1008)
2. "estimate_mode" (string, optional, default=CONSERVATIVE) The fee estimate mode.
                   Whether to return a more conservative estimate which also satisfies
                   a longer history. A conservative estimate potentially returns a
                   higher feerate and is more likely to be sufficient for the desired
                   target, but is not as responsive to short term drops in the
                   prevailing fee market.  Must be one of:
       "UNSET" (defaults to CONSERVATIVE)
       "ECONOMICAL"
       "CONSERVATIVE"

Result:
{
  "feerate" : x.x,     (numeric, optional) estimate fee-per-kilobyte (in BTC)
  "errors": [ str... ] (json array of strings, optional) Errors encountered during processing
  "blocks" : n         (numeric) block number where estimate was found
}

The request target will be clamped between 2 and the highest target
fee estimation is able to return based on how long it has been running.
An error is returned if not enough transactions and blocks
have been observed to make an estimate for any number of blocks.

Example:

bitcoin-cli estimatesmartfee 6


How to get BTC transfer amount from raw tx using bitcoinjs Suppose I have following object

console.log(bitcoinjs.Transaction.fromHex(rawTx));

The output

Transaction {
  version: 2,
  locktime: 1655960,
  ins: [
    {
      hash: <Buffer dc 4d aa 10 db 80 36 52 24 49 7c c5 7c bc c5 bc df be e1 2d 58 61 70 e1 0c 7b 76 a7 35 cc 7c 3a>,
      index: 21,
      script: <Buffer 16 00 14 5f f3 9b e6 42 af a9 f3 59 25 34 e7 6a dd b2 ee e3 41 82 15>,
      sequence: 4294967294,
      witness: [Array]
    }
  ],
  outs: [
    {
      value: 1000000,
      script: <Buffer a9 14 14 ea 69 2e 87 76 ec c6 2e 6a aa a1 7d cc d2 8f f3 30 b7 46 87>
    },
    {
      value: 3299775,
      script: <Buffer a9 14 73 e2 99 78 43 31 1e cc 32 b5 ac 38 ef c9 9b b3 ae 54 bc 7c 87>
    }
  ]
}

How can I decode transfer amount (in BTC) from this object?

The transfer amount (BTC) is, (somewhat dependant on the library used),  most commonly denominated as "value:"
Read: the outs => value: *

 {
      value: 1000000,
      script: <Buffer a9 14 14 ea 69 2e 87 76 ec c6 2e 6a aa a1 7d cc d2 8f f3 30 b7 46 87>
    },
    {
      value: 3299775,
      script: <Buffer a9 14 73 e2 99 78 43 31 1e cc 32 b5 ac 38 ef c9 9b b3 ae 54 bc 7c 87>
    }

Where the value is most often denominated in satoshis (a single unit.). But, some block explorers (blockchair) or other libraries will denominate in single units of Bitcoin, as is done below. (10^8 satoshis - 1 BTC ( 100 mil))

1000000 = 0.01BTC
3299775 = 0.03299775 BTC


How can I get the date of the last transaction from the blockchain.info API? Is there a way to request the date of last transaction via API? I run a request to see balance of my addresses and need to request the date of the last transaction, how would I do that?

This is an ambiguous question as we don't know what your environment is.
If you are using bitcoind, a call to gettransaction will give you a time field which is when the transaction has been seen.

Perhaps if you elaborate a bit more we would be able to answer the question more specifically.


Couldn't an attacker cause online (watch-only) wallets to display malicious receiving addresses? If I understand correctly, one of the main perks of using a deterministic watch-only wallet is the ability to generate new receiving addresses without syncing with the offline wallet, but this seems vulnerable to attack.

Example:

To prevent an attacker from stealing her funds, Alice keeps her private keys in an Armory offline wallet. She uses an [online] watching-only wallet to generate receiving addresses, which seems to be recommended by Armory's page Using Our Wallet:

  Now that the wallets are setup, you can use the watching-only wallet exactly the same way as a regular wallet, except Bitcoins cannot be sent from it.   Use the “Receive Bitcoins” button to generate addresses for receiving payments, and incoming transactions will show up in the ledger with a slightly different color than your other wallets.

A similar suggestion on the Electrum tutorials page:

  You now have an online wallet where you can check your balances and give out new addresses, but you can't however spend the coins. So if an attacker would be able take over your online computer your coins can't be lost.

Eve creates a modified version of Armory in which all new receiving addresses (created when the user presses "Receive Bitcoins") are owned by Eve instead of Alice.
Eve gains access to Alice's online computer and plants the modified version of Armory. Now any payments received by Alice's new addresses are actually under Eve's control, without her knowledge.

Obviously you could generate the receiving address a second time on the offline wallet and verify that they match, but doesn't that defeat the purpose? Also, shouldn't there be a warning about this?

Yes, this is possible. However, since Bob (actually, in cryptography, usually Eve, the attacker) has, apparently, got access to Alice's computer, he/she could also replace the Bitcoin application with one that does the same thing.

The purpose of this procedure is to protect Alice's existing bitcoin. It does not do other things.


Salvaged possible wallet from corrupt HDD ... now what? In short,

I bought a few BTC years ago when they were very cheap.
I reformatted my HDD and reinstalled the OS.
I have used PhotoRec and
http://www.cyplo.net/2012/04/01/bitcoin-wallet-recovery-photorec/ to
recover 3 .dat files. Searching only for the ''detection signature''
of a Bitcoin wallet.dat

And the confusing part (if reformatting a hard drive containing bitcoins was not confusing enough!) is that the recovered .dat files are 7GB , 13GB and 8 kb.

Obviously, trying to use the recovered wallet.dat with Bitcoin-qt failed.

Chances are that these .dat are not wallets but I though this would be worth a shot considering how massively more valuable BTC are compared to 3 years ago.

Anything I can do with these recovered files?

Thank you!

Install Python 2.7 and download pywallet to your c:\ drive.
Copy your corrupt wallet.dat file to c:\
Open a Command Prompt and type:

C:\>pywallet.py --dumpwallet --datadir c:\  --wallet=wallet.dat --recover --recov_device=c:\wallet.dat --recov_size=416Gio --recov_outputdir=c:\

It should extract all the keys to a new wallet on c:\
Copy the new wallet.dat to the c:\users\USERNAME\Appdata\Roaming\Bitcoin folder
rename it wallet.dat.
Start up Bitcoin-QT with the --rescan switch.
It should take a while, but eventually it will start up and your coins are back.


Windows vs Linux for bitcoind (not mining) What is the best O/S for bitcoind, which serves as a backbone for an online payments processor?

Right now it is set up to run under Windows but I'm not sure if this is the best choice if they underlying service will need to process more transactions per minute.

I am not familiar with Linux but wouldn't mind migrating bitcoind there if there are obvious advantages towards using it.

Relative questions (but for mining only):

https://bitcointalk.org/index.php?topic=6023.0

https://bitcointalk.org/index.php?topic=13491.0

http://www.reddit.com/r/Bitcoin/comments/i8duo/bitcoin_mining_linux_vs_windows_thoughts/

Thoughts please.

My answer will be based on my experience as I made no benchmark to prove what I say.

First I think that if you have a correct machine something like a i5 and 4GB or ram performance shouldn't be an issue on both platform (If you run Windows Server 2008 this should be the case!).

Now for If performance is really important for you I would clearly advise Linux for several reasons.

Bitcoin uses a lot of open source dependencies like leveldb, Boost or QT.
This libraries are mainly primarily coded for Unix environments and also probably optimized for them.
For example I worked with leveldb and there is no official release of leveldb work Windows. You have to path it by your own to get it working on windows.
leveldb (the database that stores the unspend output) may use a lot of ram 1GB or more. The advantage of Linux is that the operating system doesn't consume a lot of RAM (About 500mb for Debian more then 1GB for Windows 7 after start).
Generally you get better performances if you compile a program from it sources instead of installing it from it's binaries.
This is possible as well on Linux as on Windows but compiling bitcoin on Linux is much easier.

I personally run a bitcoin server on a Debian 6 machine with an Intel Atom processor and 2GB of ram. It is running fine.


Confirmations bitcoin I don't understand why there are no confirmations. It seems that I paid enough fee, but it is still pending.

Address: 1FbQh78uCcqw76jkANnK2AhygWxnAmZ8eM
TxId: e2701d27976656756db913d877cdeced1eb50c7000987a0098e145db86c5f1f2

https://blockchain.info/tx/e2701d27976656756db913d877cdeced1eb50c7000987a0098e145db86c5f1f2

Anyone know what is wrong?

Cheers,
Pieter

You paid around $15 USD for the fees, the current average transaction fee today is 41 USD. Your transaction will either take quite some time or it will need a higher fee.


Can Buy Bitcoin From Different country exchange and transfer to wallet Completely new to this I want to know that,

If I purchase bitcoin from exchange website https://bitcoin.org/en/exchanges any country Then I can transfer it to Zebpay wallet.

Because it looks good deal price is not same everywhere just transaction fee if you purchase in volume then this seems nothing.
I'm new here many peoples already tried this or may be I'm getting it wrong.

First, answering your question. Yes, you can send BTC from any exchanges/wallet to any other wallet including ZebPay's wallet.

Second, now here is where you are getting it wrong. Indian exchanges have premium values for Bitcoin because in our country India, it is very difficult to send money internationally without any strong reasons.

And even if you are able to send some money, you won't be able to do this for a large sum which can make a considerable profit for you in the long run.

Sending money internationally by wrong reasons can even get you a hefty fee to be paid and even jail.

But Indian exchanges like Zebpay, Coinsecure, Unocoin, etc make it easy and legally binding to buy BTC in our country.

So, unless someone find an easy way to send funds internationally and buy there and sell and continue this cycle, the BTC price in India atleast will be premium for that time.


Does a bitcoin node broadcast that it is full synced? When a bitcoin core node is fully synced, does it broadcast to the rest of the network that is has finished syncing? If yes, where in the bitcoin-core source code is this implemented?

No. The nodes notify only about block height in the beginning of connection in version message. When node wants to notify about new block/tx it received/created, it uses inv message.

There is no point to notify other peers about downloading full blockchain. Other nodes have nothing to do with such information.


Is there a single point generator G for every elliptic curve? I understand that G is a point on curve which holds true for y^2 = x^3 + ax + b.
But there can be several other points as well which holds true for above equation but how do we choose which one is our G?

There often are multiple points which could be generators. In fact, for prime order curves, every point on the curve is a generator.

For practical use, a specific point is picked based on some constraints.

May curves use rules such as lowest abs(x) value or use some deterministic generator with a random seed.

I can't seem to find the login behind the G selection for secp256k1, however, but the point itself is defined in the curve specification.


Can there be a half segwit, half normal Bitcoin transaction? I was wondering if it's feasible to compile a bitcoin transaction that is somewhere in between (segwit and non-segwit), maybe one of these scenarios. I'll call the non-segwit inputs, normal inputs just for the sake of simplicity.

Use one normal UTXO input and one segwit input
Use Segwit inputs but have normal outputs
Have a transaction with two outputs, one Segwit and one normal

If the answer to any of these is yes (maybe doesnt apply to the last scenario), what would be the case for transaction malleability? would the final transaction be still vulnerable to transaction malleability as the signature is still in the main transaction object?

Yes, absolutely.

Every output can independently be a normal or SegWit output (when using P2SH-embedded SegWit, you can't even tell until it is being spent).

Every input can independently spend a normal output or SegWit output.

When a transaction has at least 1 SegWit input it's called a SegWit transaction.

When not all inputs are SegWit inputs, the transaction is still malleable.


Bitcoin wallet taking days to receive coins Previously withdrawing bitcoins from Intersango has only taken 24 hours.  This particular transaction has taken several days and I still haven't received the bitcoins.  I withdrew the coins from Intersango but they haven't been received by my wallet yet.  Does it make a difference that shortly after I withdrew the coins from Intersango I encrypted my wallet? Does it make a difference that it is currently 'locked,' if so how do I unlock it to recieve coins? Please somebody help this is really worrying me!

Intersango has been having a problem with their wallet recently, as described in this forum post.  Another post claims that:

  this was triggered by someone spamming the wallet with a very larger
  number of small transactions

Encrypting your wallet won't make any difference to whether you receive the bitcoins or not.  You only need to "unlock" the wallet to spend coins (or to top out your pool of unused addresses).

You can check at http://blockchain.info/address/1youraddresshere to see whether the coins have been sent yet.  If they show up there but not in your wallet then it's an issue with your wallet.


How to install a private testnet? I'm looking to make my own NxT testnet for developpement purpose but couldn't find a way to do it.

I'm currently using the normal " testnet " but couldn't find the way to properly configure the nxt-default.propreties so that i could make local testnet.

Do you guys have any pointers ? or config files ? Will i be able to use my testnet on the same computer or should it be run on a server the same way a public node would ? What about setting up the configure of the genesis block , etc ?

Hope you guys can help

See https://nxtforum.org/testnet/public-testnet-node/ for a description how to setup a testnet node.


How do I get started in finance & market analysis? I'am currently new to bitcoin & doesn't any finance or market background, currently I got huge interest to how this currency system will affect our life, as I spend more and more time reading about bitcoin, then I feel I need more knowledge about how finance world work, and how to do market analysis.

Can you give me a point where I should start learning about finance especially the one is connected to this bitcoin things?

Market analysis usually consist of Fundamental Analysis and Technical Analysis.

I recommend http://www.babypips.com to get started with the the Technical Analysis.

Fundamentals consist of understanding how the economy is effected by news and business. Social psychology to specific events and can vary depending on what market your looking into.


Retrieving my unspent Bitcoin output I have sent my only begotten BTC from my exchange currency account but not yet received in my blockchain wallet, and when I inquire with my transaction ID, I found my the transaction to be stuck for four days now... So, it seems to be there and but it is not clear when it will be released to my account. Should I be able to retrieve them back to a senders account.

Can we have that option please so that we can be safe and able to make some other options to use our money.

This thing of unspent outputs and stuff delays us to the business and for security being we won't trust the network for the fact that many are transaction awaited on an unknown same address. Those transactions stays for a long period of times.

Can we please given only an option to retrieve them back not anything else we may need on this. Maybe it could even ease the system to flow easy and transparent to us.

I'm afraid this is how Bitcoin works, and there is little we can do about it. Think of it like a bank transfer you initiate on a Friday, it has to be processed by the bank at some point in time, only banks do not settle transactions during weekends, and large backlogs will further delay the processing. Now replace the centralized bank, with the Bitcoin blockchain. While it does not have holidays, it does have to deal with backlogs.

In times of a large number of transactions hitting the network at the same time the backlog grows, and this has been the case for the last few days, since the network's capacity is lower than the influx of new transactions. You can get ahead of the queue by adding more fees to your transaction (try looking for RBF or CPFP), but in order for the backlog to be reduced we need some time (usually weekends) when the capacity of the network exceeds the influx of new transactions.

We can also not retract transactions, since that in itself would be another transaction that needs to be processed, and even worse, all nodes in the network would have to agree to discard the transaction, which is in itself a consensus problem, which is why we had to come up with the whole blockchain business in the first place.

So, while it certainly is frustrating having to wait for confirmations, it'll eventually confirm, and you can influence your position in the queue by adding more fees, replace-by-fee, or child-pays-for-parent.


What is the most widely distributed crypto currency? I've been doing research to find a crypto-currency that is "fairly" distributed among the population. Being "fair" is quite subjective. We can all agree that 10 people that control a coin is not fair, but what about 100? or 1000? or 10,000?

So the question is, which crypo currency or currencies have the most distribution? And the other question is distribution the same as adoption?

As you noted, a lot of this depends on how you define your terms. In an Objectivist sense, all currencies are equally fair. :)

If we look at fairness in terms of information disparity, we can see some clear winners and losers. Information disparity is important because if insiders know that their coin is technically sound before the general public does, they can snap up coins while they're cheap.

SolidCoin had 50% of its mining controlled by special accounts that were handed out to secret parties in a secret process. (Or possibly they weren't handed out at all. There's some disagreement on that point.)
Litecoin published its source code prior to it's launch, and allowed people to mine on a test network. At launch, its code was well-understood.

If we define fairness in terms of "one person, one coin:"

AuroraCoin is a clear winner. They issued an equal amount of coins to all icelanders. They actually verified that the people claiming coins were distinct people, and not scammers.
One of the heavily premined altcoins (there's plenty of 'em to choose from) is a clear loser.

You also ask about which coin has the most distribution, which is a different question from which one is distributed the most fairly. In terms of active users, Bitcoin probably still has the most users. (Dogecoin is catching up, though.)

In terms of inactive users, AuroraCoin theoretically has 300,000 owners. (Of course, by that measure, you could increase adoption of your *coin of choice by putting money into private keys and emailing them to random people on the Internet.)


Multi-sig N of M where 1 of the keys can see the balance but not spend (read-only key)? If I had a non-HD multi-sig wallet, checking the balance of it would be trivial (I would just look at the blockchain to see the address' balance, without the need to hold a key).

However, with HD wallets, a wallet is comprised of N addresses. So knowing the balance of this wallet is not easy unless you are one of the key holders.

Therefore, this is my question: how to know the balance of a multi-sig HD wallet, from a read-only standpoint? Can the distribution of the keys be asymmetric so that there's one key that allows checking the balance but doesn't allow signing?

The author of this paper seem to have put some thought into the problem you describe and has proposed a solution that seems relevant to your question:

A new HD wallet that tolerates key leakage
Master key generation. Instead of one master private key, our HD wallet uses
m master private keys ˆd1, . . . ,ˆdm for some reasonably-sized m to be determinedby the requirements of the wallet. (For example, in the combined treasurer-auditor use case of Section 2, m must exceed the number t of departments in the organization.) To keep the master private key size down, these master private keys could be generated pseudorandomly with no loss of security using, say, therudimentary deterministic wallet described in Section 1.*

https://eprint.iacr.org/2014/998.pdf


How to findout the sender of a transaction How do I find out which addresses are the inputs of a given transaction, given its transaction ID?
I know there is a way, as satoshidice.com uses this.
I would like to do this with own software and not rely on some third party provider, which could easily kill their service.

EDIT:

Basically I'm creating a PHP project, where I need to find out when a new transaction arrives and which address sent it. So I need a way to get a notification or start a PHP script (called with needed variables [txid, sender address, receiving address, value]) when a new transaction arrives.

I just answered a similar question. The relevant parts are:

It is now possible to determine the list of addresses that sent a transaction using the raw transaction JSON-RPC API calls that were released with bitcoind and bitcoin-qt version 0.7. The pseudo-code to accomplish this is:

txid = <relevant transaction id>
addresses = []
raw_tx = decoderawtransaction(getrawtransaction(txid))
for(input in raw_tx['vin']) {
  input_raw_tx = decoderawtransaction(getrawtransaction(input['txid']))
  addresses.push(input_raw_tx['vout'][input['vout']]['scriptPubKey']['addresses'][0])
}


How do you download blockchain data (transactions etc.) using a node? Best ways to get a node? I am just curious how one can download bitcoin data and blockchain using a node. Where should I start?

I am just curious how one can download bitcoin data and blockchain using a node

One way is to download and install a full-node desktop wallet such as Bitcoin-core.

When it is first started it will download the full blockchain. This may take a week - depending on your Internet-connection's bandwidth.

  Where should I start?

https://bitcoin.org/en/ is probably a reasonable place to start.

Ask questions here (one at a time) about any problems understanding or using Bitcoin. But use the search function here first - lots of great answers already exist for many problems.


In what scenarios can the blockchain size decrease for bitcoin? I am running a private bitcoin network for which I changed the target time between two blocks to 12 seconds and the difficulty adjustment to 25 blocks interval. I ran the network for about 4 hours with 50 nodes. In one of the node's logs I observed that the blockchain height increased up to a maximum of 181 and then started decreasing, all the way to 38. what could be an explanation for such a strange behaviour.

Please refer to the log below:

2015-11-04 01:58:47 receive version message: /Satoshi:0.11.99/: version 70011, blocks=181, us=0.0.0.0:0, peer=2, peeraddr=127.0.0.1:44117
2015-11-04 01:58:47 UpdateTip: new best=0000005265ca4ce01ad0d06f45cf475bf303de3d64e942c5cf1177e00f346c78  height=180  log2_work=37.083283  tx=30941  date=2015-11-04 01:53:17 progress=1.000000  cache=0.0MiB(1tx)
2015-11-04 01:58:47 UpdateTip: new best=00000052a34cedf3c5ddbeb46d36644654523db855c4cce984d2623e840dd219  height=179  log2_work=37.082953  tx=30940  date=2015-11-04 01:53:10 progress=1.000000  cache=0.0MiB(2tx)
2015-11-04 01:58:47 UpdateTip: new best=00000030fd7652affb883f05fe0c98e7fe3fbc3cfd74808e061ed05ec61c22e6  height=178  log2_work=37.082623  tx=30939  date=2015-11-04 01:52:55 progress=1.000000  cache=0.0MiB(3tx)
2015-11-04 01:58:47 AddToWallet c32bcbd8102c602a5e71ee717232e204435f331dce6fbfb9eb5d552698faa95b
2015-11-04 01:58:47 AddToWallet 1c91517aeadd12bcbcfdf4a1423b671d405543ae9abfbd87078969ce1971663f
2015-11-04 01:58:47 AddToWallet b11f9c2e3b1ab3d3983da63783bb95903d89405243d0716ea88272a9261b7a33

It looks like this part of the code is what was adding all those UpdateTip messages:

https://github.com/bitcoin/bitcoin/blob/8fe30fb4d130532d4a0e4c9d143f03e1b85a749e/src/main.cpp#L2234

Essentially, bitcoind thinks another chain with more cumulative work exists on your 4-node network, though from the logs, it's hard to tell how much lower it goes. You'll have to run it for longer in order to find out.


How to get bitcoin wallet name from bitcoin address In http://bitcoinwhoswho.com/ , we can find wallet name from bitcoin address, how do they do so? Is there any signature of wallet name in bitcoin address or in transaction id?

Welcome to Bitcoin.SE!

I have had a quick look at the website you referenced specifically, however, it suggests most of the information that they have is because people have 'claimed' their address and provided the details.

If you have a look at this example, that represents just about all that is publicly obtainable when someone makes a transaction + the public keys. And, website information, names and, labels is not sourced from the blockchain.


Is there some way to safely prove that you control a certain number of Bitcoin? I want to know if there is some Bitcoin Core-supported feature where it takes the current amount in your wallet.dat and dumps it in such a way that another person can take the data and verify that you own X amount of Bitcoin, obviously without giving up the private keys/control of the coins, and somehow tying them to an arbitrary string, such as a real name, nickname, e-mail address, greeting of some kind, etc.

If this is possible, how is it done and how does it work on a technical level?

And is/could this be done without actually revealing which coins/parts of coins you control? Only that you have X amount of BTC in your wallet.dat?

And how easy is it to verify this "public coin proof" blob of cryptic characters? One might guess that most people would just look at the amount of Bitcoin on this "receipt", that greeting text, and the encryption-looking text following it and assume that it must be the right person, without actually feeding it into Bitcoin Core. So it should be very simple to verify, such as being able to drag and drop the file/image into a Bitcoin Core GUI window and immediately get a "Correct: X BTC" alert box pop-up, or a "Could not verify proof blob." error message.

Most Bitcoin addresses are derived using public key cryptography, so in the same way that our wallet can use a private key to sign a transaction that spends some BTC, it can also use a private key to sign an arbitrary message (in this case, a message that says "I own this address!").

As example: By using the private key that controls a funded bitcoin address, you can prove that you own the coins stored at that address (or at least, you can prove that you have knowledge of the private key that can spend them). Lets say Address X has 1 BTC, and so you create a message that reads 'Address X is controlled by Takwon', and then sign that message using the private key for Address X. You can now pass this signed message to someone, and they can verify that you do indeed have knowledge of that private key.

This post has info about how to create a signed message using bitcoin-cli:
How to sign a message using Bitcoin private key?

This post has info about how to verify a signed message using bitcoin-cli:
How can I verify a signed message?

This post has info about the nature of the signed message - to be absolutely sure that someone owns the address in question, you should provide a message that they will sign.
If someone wanted to pretend to be Satoshi by posting a fake signature to defraud people how could they?

  And is/could this be done without actually revealing which coins/parts of coins you control? Only that you have X amount of BTC in your wallet.dat?

The method above reveals which address(es) you control to anyone that is verifying the signed message(s). I am unaware of any method that would allow you to prove ownership of some amount of coin, without revealing which specific UTXOs constitute those funds. Perhaps there is some fancy ZKP math which could be done on a UTXO set commitment to accomplish this, but as far as I know no such thing has been developed for Bitcoin at this time (and, perhaps it is not possible, I'll leave that to the cryptographic experts to explain in more detail).


Why does the value range of outputs need to be restricted? In the 'tx messages' section for protocol rules we have

Each output value, as well as the total, must be in legal money range

For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction

If my understanding is correct, rule 4 will confirm 0 <= output, sum of outputs <= 21,000,000, and rule 12 is checking that each input is in the UTXO set. I am having a hard time seeing why rule 4 is necessary, it seems like other rules - such as rule 12 - would already invalidate a transaction that was not in legal range. No one could ever have > 21,000,000 bitcoin so there could never be utxos for more 21,000,000.
Also, where can I find the code for these checks in the source code.

If the output value was only constrained by their sum being smaller than that of the inputs, you could e.g. set one output to a negative value and create new money in a second output.
You can also do more creative stuff:
I think the rule might have been introduced as a response to the value overflow incident on 2010-08-15. A transaction in a (now invalid) block at height 74638 created outputs that were so large that their sum overflowed into the permitted range. The transaction created 2×92.2 billion bitcoins.
The original code fix for the value overflow incident can be found here: https://github.com/bitcoin/bitcoin/commit/d4c6b90ca3f9b47adb1b2724a0c3514f80635c84#diff-118fcbaaba162ba17933c7893247df3aR1013
The code for this rule can be found in src/consensus/tx_check.cpp here. The CheckTransaction() function checks consensus rules that don't require any knowledge of the current chainstate.


Find sender's public key in SegWit Transaction How can I retrieve the sender's public key in a Segwit transaction?

For example: https://www.blockchain.com/btc/tx/3179d18d6f36fa77b88909496535485d8188d96b79d295843789a9e0ff6c3e6a

I can happily parse the witness part as in

02 : 2 items to follow

47 : 0x47 = 71 bytes (signature)

304402201cf8db0c4afc164970ec4397327fe9b1dd9b7ff4a9093f94e554d624b5ffdcb702202848072c17f2bcce16b8d3d7cb2efdad87bc6c942b79f44b79f1c52f817d81ea01 : the actual signature (last byte is the sighash code)

21 : 0x21 = 33 bytes (the pubkey)

02384052a5ecde83bf8ee7ed77f378edb58aa65de22c4e91af87eee68015b9d509 : the actual pubkey

But this pubkey is not the public key of the sender. It's probably the pubkey of a segwit (or something like that)...

How exactly is this signature made up and what pubkey is that? And more importantly, how can I retrieve the sender's public key (the one belonging to 35yfMa3CRBiWny8DFdb4tUu9fn7fcdvVp9 in this example).

The public key that you mentioned is indeed the key that was used to derive the P2SH(P2WPKH) address: 35yfMa3CRBiWny8DFdb4tUu9fn7fcdvVp9. The way in which a P2SH(P2WPKH) address is derived is as follows:

1. witness_script = hash160(pub_key) #this is equal to '4b9d2d3dd1174ad656754a0c664e7a129b131f3b'
2. witness_version = 0x00  #current SegWit version
3. scriptSig = witness_version + OP_DATA(0x14) + witness_script
#Above is equal to '00144b9d2d3dd1174ad656754a0c664e7a129b131f3b' and is the one you are seeing in the scriptSig in the explorer.
#0x14 tell the script to push the next 20 bytes to the stack
4. public_address = hash160(scriptSig)
5. bitcoin_address = base58check(public_address) #with prefix of 0x05
result = 35yfMa3CRBiWny8DFdb4tUu9fn7fcdvVp9

Native SegWit transactions works by locking an output with scriptPubKey: version + OP_DATA (bytes to push) + witness_script. For older clients, this looks as if it is any one can spend transaction, as it does not have an opcode verifying anything. So in order to take advantage of lower fees of spending SegWit transaction, but at the same time be compatible with wallet software that are not SegWit aware, we use the scriptPubKey as the script and create a P2SH locking script out of it. So the locking script is: OP_HASH160 <public_address> OP_EQUAL. (public_address convention is same as the one I mentioned when deriving the address above). So a customer can send you bitcoins without upgrading his wallet software to be SegWit aware, but when spending the bitcoins, you can take advantage of lower fees of SegWit.

Now, in terms of verification when this output is spent in a transaction: Older clients verifying the transaction will just look at the scriptSig, take its has160, verify with the public_address and consider this transaction to be valid. Newer clients will realize that the scriptSig is in itself a SegWit and will look for signatures in the Witness part of the transaction. There the clients will verify that the hash160 of the public key is equal to the witness_script and then the signature matches the public key when signed with the transaction as a message. The signature message digest is described in BIP 143.


Accessing a previous wallet A couple of years ago I purchase a little Bitcoin. I don't know where I purchased it through, but I do have the Wallet Name, Wallet Address, and Wallet Key. How do I retrieve it? Can I access it through any exchange? I'm confused here a little.

Not sure what you mean with Wallet Key but if you mean the password for access to your wallet in the exchange then this will only work in that exchange.

Please search for your address here to verify that your coins haven't been transfered somewhere else.

In case you were provided with a seed then you can use this seed in a wallet like Electrum or Mycelium (an Android app) to recover your funds :)

If you don't have the seed then you better remember where you purchased your bitcoins! :/ Maybe checking your search history or your inbox?


On-chain scaling still required with Lightning Network? I'm wondering if/how Lightning Network relieves us of on-chain scaling on the road towards mass-level adoption. As I understand, payment broadcasts are deferred to the point in which the channel is closed, whereupon they are bundled and settled via consensus. Seems to me that although funds can be transferred hand to hand instantaneously, if we achieve global adoption, Lightning Network spends may still congest the mempool when they are finally broadcasted.

Discussion on page 52 of the Lightning Network whitepaper DRAFT Version 0.5.9.2 (after this was answered):

  If we presume that a decentralized payment network exists and one user
  will make 3 blockchain transactions per year on average, Bitcoin will
  be able to support over 35 million users with 1MB blocks in ideal
  circumstances (assuming 2000 transactions/MB, or 500 bytes/Tx). This
  is quite limited, and an increase of the block size may be necessary
  to support everyone in the world using Bitcoin. A simple increase of
  the block size would be a hard fork, meaning all nodes will need to
  update their wallets if they wish to participate in the network with
  the larger blocks.

  While it may appear as though this system will mitigate the block size
  increases in the short term, if it achieves global scale, it will
  necessitate a block size increase in the long term. Creating a
  credible tool to help prevent blockchain spam designed to encourage
  transactions to timeout becomes imperative.

Yes, it would require on-chain capacity increases if there were a lot of channels being opened and closed as well as normal on-chain transactions. This need is directly referenced in the Lightning Network paper itself.


How does the Bitcoin p2p network work? Does it need port forwarding? But does every peer node in the bitcoin p2p network need to have ports forwarded in order to participate? Otherwise, how does the p2p network work in the Bitcoin network?

I heard that there are some technologies for implementing peer-to-peer networks such as UPnP and Hole Punching, does Bitcoin use any of these technologies for its p2p network?

Nodes that participate in the Bitcoin network run a computer program such as this one: https://github.com/bitcoin/bitcoin, which dictates how everything works.

To answer your more specific questions:

Yes, bitcoin once used UPnP, here are some more details: https://dirkmittler.homeip.net/blog/archives/3340 but in modern versions it does not (thanks for specifying this the comment section).
Bitcoin uses TCP, and hole punching over it is not reliable.. Here's another place where this is briefly touched upon Can exist bitcoin network with all nodes behind NAT?


When was the first GPU miner made available publicly? The GPU miners are widely used nowadays, but that wasn't always the case. When was the first GPU mining software made available publicly?

This post from SmokesTooMuch seems to be the first time GPU mining was suggested:

Suggestion :
Since the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.
So, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA.

Here's satoshi in December 2009 asking for people not to use GPUs to mine:

We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network.  It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility.  It's nice how anyone with just a CPU can compete fairly equally right now.

So it seems the idea was around for a long time before the savages broke the gentleman's agreement.  :)


What is the weight of a block that contains no pay-to-witness scripts? I'm trying to understand block weight, a metric introduced by segwit (BIP-141):

block weight = 3 * base size + total size

"base size" is the length of a pre-segwit block, which contains only serialized base transactions. "total size" is the length of a post-segwit block, which contains both serialized base transactions and serialized witness transactions (as defined in BIP-144). The weight of any block must not exceed 4 MB.

The weight of a block without pay-to-witness scripts can found by computing total size. It's tempting to set base size equal to total size:

block weight = 3 * base size + base size = 4 * base size

But this assumes the length of the serialization of a non-segwit base transaction equals the length of the serialization of a non-segwit witness transaction. This doesn't appear to be the case:

The witness transaction serialization format appears to follow the structure shown above (which is also the input to find wtxid). Notice two additional bytes before the list of inputs (marker and flag, respectively). Moreover, the witness requires at least one byte (the witness field count) even if no fields are present.

In other words, a witness transaction serialization will always be at least three bytes longer than a base transaction serialization, regardless of whether a witness is present.

If this is correct, then segwit is in fact reducing the block size limit for blocks devoid of pay-to-witness scripts by a factor proportional to the number of transactions in the block.

What am I missing?

The witness serialization format only applies to transactions that have witnesses. If a transaction does not have witnesses, then its witness serialization format is the non-witness serialization format.

From BIP 144:

  If the witness is empty, the old serialization format should be used.


Why does the mainline client limit the number of outbound connections to 8? The mainline Bitcoin client limits number of outbound connections to 8 however allows up to 125 total connections.  To achieve greater than 8 connections (due to outbound limitation) requires either using uPnp or port forwarding so that the client can accept inbound connections.

Why is there a limit of 8 connection and only on outbound connections?  Why not allow the client to create 20 or 125 outbound connections?

This is a legacy issue.

When the network was first implemented, there was a severe shortage of servers that could reliably accept inbound connections. Many people started running the client behind NAT and they could not accept any inbound connections. Meanwhile, they were consuming the available inbound connection capacity of the more limited number of machines that could accept them. The client now enables uPNP traversal by default.

Second, there were problems with the client code that caused it not to be able to support as many connections as it should have been able to. Many nodes could not even support the default 125 connections, even though their CPU and network usage was nowhere near maxed.

These days, it's just kind of stuck. My 'hub mode' patches make it easily possible for clients to support 1,500 connections. But they almost never see more than 200 clients because the network capacity limitations are long gone.

You need a healthy number of outbound connections because a malicious adversary can consume all your inbound connection slots by repeatedly connecting to you, and staying connected, from a variety of IP addresses. The Bitcoin client actually has code to try to get IP diversity in its outbound connections to protect against some entity creating a million servers and having a high chance of getting all 8 of your outbound slots.

If you're paranoid, turn this up. You can still configure for 32 outbound connections if you can also add at least 64 inbound connection slots in exchange. You'll be helping the network. You can use my hub mode patches to do this.