What is the best Lightning implementation to obtain the network graph? I want to obtain a fresh snapshot of the Lightning network from my own node. So far I've experimented with Eclair, its API calls allnodes, allchannels, and allupdates give me the information in the following format (examples from testnet).

A node:

{
    "signature": "304502210091f498ae307be653c3dc54954e4e20fcf1a42ff6f0ff7cfe9f1b4367f64349f2022069931b88e1a05cf16ebd08a7272f2249ec47816c9bda51d7b1b4c70b35ed580001",
    "features": "",
    "timestamp": 1543424260,
    "nodeId": "03be1602dd945198ad92b96ed6de85ba41d6c69cc5e81826d5d05a176bf9a38fcd",
    "rgbColor": "#e20f00",
    "alias": "shangod1933e2a-3f17-4",
    "addresses": [
      "54.242.15.59:9735"
    ]
  },

A channel:

{
    "shortChannelId": "1288195x260x0",
    "a": "02ece82b43452154392772d63c0a244f1592f0d29037c88020118889b76851173f",
    "b": "03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134"
  },

An update:

{
    "signature": "3045022100fb115950efdeb745d16e79b13be18d01a02c66f2bad0a2050ac157f70e51fe9502201694b2ff817bd5a1bc44488e9732e233f2ca93528df5cbe134ecc2555e7b2a5601",
    "chainHash": "43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000",
    "shortChannelId": "1448407x42x1",
    "timestamp": 1560197957,
    "messageFlags": 1,
    "channelFlags": 0,
    "cltvExpiryDelta": 144,
    "htlcMinimumMsat": 1000,
    "feeBaseMsat": 1000,
    "feeProportionalMillionths": 1,
    "htlcMaximumMsat": 16777215000
  },

Do other implementations (LND, c-lightning) provide the same information (maybe in a different format)? If I want to get the most available information about nodes and channels, should I stick with Eclair or switch to another implementation?

So in c-lightning you have the two api calls listnodes and listchannels

here are sample outputs from a mainnet c-lightning nodes:

"channels": [
    {
      "source": "0250373555232cec757ea141273e75381c84cc3ab22f1e3a3ca5a2dc55b1904c24",
      "destination": "02ef61a252f9504a42fc264a28476f44cea0711a44b2da0bd729ad52aaee9d86b7",
      "short_channel_id": "505149x622x0",
      "public": true,
      "satoshis": 300000,
      "amount_msat": "300000000msat",
      "message_flags": 1,
      "channel_flags": 0,
      "flags": 256,
      "active": true,
      "last_update": 1559441480,
      "base_fee_millisatoshi": 1000,
      "fee_per_millionth": 10,
      "delay": 14
    }

and

"nodes": [
    {
      "nodeid": "039f96b5dc60b60596dafc870ae104beb6cfaa40aa718b3e9dab9db6b1e52ed3b8",
      "alias": "DACSC",
      "color": "3399ff",
      "last_timestamp": 1559456735,
      "globalfeatures": "",
      "global_features": "",
      "addresses": [
        {
          "type": "ipv4",
          "address": "92.86.218.107",
          "port": 9735
        }
      ]
    }

on the other side if you use lnd there ist the listnetwork command which prints a large json blob which has two fields nodes and edges

for a random node the entrie looks like that:

"nodes": [
    {
      "last_update": 1559598407,
      "pub_key": "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
      "alias": "OutaSpace ",
      "addresses": [
        {
          "network": "tcp",
          "addr": "46.163.78.93:9760"
        },
        {
          "network": "tcp",
          "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
        },
        {
          "network": "tcp",
          "addr": "2dkobxxunnjatyph.onion:9760"
        },
        {
          "network": "tcp",
          "addr": "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
        }
      ],
      "color": "#123456"
    },

and for a random channel it looks like that:

{
    "channel_id": "564791635544965120",
    "chan_point": "4297b5fe9beeb701c67fd0f84861b22edbcafe5c25be67324ab11129226356a1:0",
    "last_update": 1552879381,
    "node1_pub": "028aa5a991a2acf33da91674fe062219b640e5e57d77a48de6df3c0d30be22b05b",
    "node2_pub": "03fab7f8655169ea77d9691d4bd359e97782cb6177a6f76383994ed9c262af97a5",
    "capacity": "50000",
    "node1_policy": {
      "time_lock_delta": 14,
      "min_htlc": "1000",
      "fee_base_msat": "1000",
      "fee_rate_milli_msat": "10",
      "disabled": false,
      "max_htlc_msat": "0"
    },
    "node2_policy": {
      "time_lock_delta": 144,
      "min_htlc": "0",
      "fee_base_msat": "1000",
      "fee_rate_milli_msat": "1",
      "disabled": true,
      "max_htlc_msat": "50000000"
    }
  },

so you see the information is in all cases eclair, lnd and c-lightning pretty much the one from bolt 07 and the gossip protocol. just the formatting is different. There are slight changes with also showing signatures of messages but the core info is the same.


Create a 2-of-3 multisig raw transaction I would like to create a Bitcoin transaction with a single input and a single 2-of-3 multisig output that pays 1 BTC to any 2 of the following 3 keys:
02983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d, 03548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0, and
0218a240a599ba437cb1458966eb456d9f848e5bdef45ea0ee4ec31fc40aa4ffa8.

I just want a syntactically valid transaction, the reference to the UTXO does not have to exist.

Could you please guide me through the steps?

You almost have it, you just need to make sure you are creating a transaction with an output that your wallet can sign.

Example (on regtest)

bitcoin-cli -regtest addmultisigaddress 2 '["02983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d","03548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0","0218a240a599ba437cb1458966eb456d9f848e5bdef45ea0ee4ec31fc40aa4ffa8"]'
￼
{
  "address": "2NA1HC31wqFexbpp8bGB6rsMR5Lz9SrUKkt",
  "redeemScript": "522102983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d2103548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0210218a240a599ba437cb1458966eb456d9f848e5bdef45ea0ee4ec31fc40aa4ffa853ae"
}
￼
bitcoin-cli -regtest getnewaddress
￼
2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63
￼
bitcoin-cli -regtest generatetoaddress 110 2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63
￼
[
  "7e974615714bdcee6f4c69ea158b92fe2c0b728742110737e7ff13d9e8eb49ad",
  ...
]
￼
bitcoin-cli -regtest listunspent
￼
[
  ...
  {
    "txid": "9c9298a5d7ceca73f657110c0222ee606324263694d59722a2194b22ccc8b0ff",
    "vout": 0,
    "address": "2NAsEawSCjsjJjtAZcpP9jhXojqNUevjo63",
    "label": "",
    "redeemScript": "0014821824c23b9c82fa639789bc3314194d1e44ec4a",
    "scriptPubKey": "a914c1499c99d26f5bb7101f1213747bf730c4b9346287",
    "amount": 50.00000000,
    "confirmations": 102,
    "spendable": true,
    "solvable": true,
    "desc": "sh(wpkh([29b8db74/0'/0'/0']03557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee))#25k8n2ql",
    "safe": true
  }
]
￼
bitcoin-cli -regtest createrawtransaction '[{"txid" : "9c9298a5d7ceca73f657110c0222ee606324263694d59722a2194b22ccc8b0ff","vout":0}]' '{"2NA1HC31wqFexbpp8bGB6rsMR5Lz9SrUKkt":49.999}'
￼
0200000001ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000000ffffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d48700000000
￼
bitcoin-cli -regtest signrawtransactionwithwallet 0200000001ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000000ffffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d48700000000
￼
{
  "hex": "02000000000101ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000017160014821824c23b9c82fa639789bc3314194d1e44ec4affffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d487024730440220249224a99d24a0ae1d91328ea2e8da0936916ea31a28e35013de003af72f658d02201c48618283ac00a8c5b362e8ade530f4cfacd396a99ab78081cea2d18ad8d165012103557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee00000000",
  "complete": true
}

bitcoin-cli -regtest sendrawtransaction 02000000000101ffb0c8cc224b19a22297d5943626246360ee22020c1157f673caced7a598929c0000000017160014821824c23b9c82fa639789bc3314194d1e44ec4affffffff01606b042a0100000017a914b7d6fcff0fe015a393f8baee424ba82c4e18c6d487024730440220249224a99d24a0ae1d91328ea2e8da0936916ea31a28e35013de003af72f658d02201c48618283ac00a8c5b362e8ade530f4cfacd396a99ab78081cea2d18ad8d165012103557ff8751b55175307c0550460694dfe3c84598672fe5b9c53dca71bcb9122ee00000000

8b0cd4413dad3e1f02f7344236ba4b3d1994c3cd3bbdda1acc9b2d2c0e184453


Why was the upper limit of 21 million bitcoins put in place? I am very new to this idea. My only knowledge of it is from the wikipedia page.

It seems odd to me that there is an upper limit at all to the bitcoins that will be issued. Perhaps there is a simple explanation to this. Why was that limit set at 21 million?

There are a lot of reasons and I don't think it's known what factors led to the final decision.

For one thing, when the basic Bitcoin mechanics were designed, there was a significant risk that Bitcoin would never be adopted. By giving a fixed term to mining and a fixed supply of Bitcoins, the original designer(s) increased the chances that people would want to acquire Bitcoins. The prospect that future scarcity would increase their value likely induced people to mine even when the economic argument for doing so was quite thin.

It's also possible that there was hope that people who didn't like inflationary currencies would be drawn to Bitcoin. There are people who see inflation as a theft or tax. The ultimate lack of inflation in Bitcoin attracted people with those views to the currency.

And, of course, some way was needed to distribute the currency. Using the initial distribution of the currency as a way to build sufficient computing power to use proof of work to secure the currency until transaction fees could take over was probably Bitcoin's biggest bit of genius.

It appears this strategy worked, at least so far.


Are people incentivized with BTC to run nodes? Bitnodes shows everyone running nodes.

Are these people incentivized to run nodes? If not, why not? If so, do node operators make some BTC from transaction fees, etc.?

Are these people incentivized to run nodes?

No. Their reasons for running a full node varies. Some of them want Bitcoin to succeed. Some of them are merchants and run a full node as part of their business. Some of them have spare computing power, and don't have a strong preference as to how it's used.  It's worked out reasonably well so far.

  If not, why not?

It's extremely challenging to prove that you're running a full node. This code pretends to be a full node, though it really just forwards requests it can't answer to other nodes.

  If so, do node operators make some BTC from transaction fees, etc.?

No. Miners receive transaction fees, although it's not a substantial part of the overall block reward. (Most node operators are not miners.)


Relay bitcoin transaction attack A user sending coins broadcast transaction hash to bitcoin network. Now if someone is able to copy the message (hashed transaction) and relay it multiple times it could lead to possible disruption.

Eg:

Node 1 sends a transaction to node 2. Node 2 forwards to node 3 and so on. This transaction gets mined.

Now what will happen if node 2 will try to relay the same message again?

How this is prevented in bitcoin network?

Now what will happen if node 2 will try to relay the same message again?
How this is prevented in bitcoin network?

The transaction is the same as one that the nodes have already seen; it has the same txid, so they will ignore it.
Bitcoin does not use an accounts based system. Rather Bitcoin uses a transaction outputs model, so each input directly references a transaction output that is being spent. So there is no problem with transactions being replayed; they have already been seen so they're just duplicates that can be ignored.


Error transferring bitcoins to another wallet I'm a beginner in the bitcoin context.
I opened an account online with Bitpanda and I have a wallet on my computer with Bitcoin core.
I bought some bitcoins for testing and I want to move them into my Bitcoin core wallet.
But everytime that I try the transfer, bitpanda says me that my internal wallet does not have enough bitcoin but I did not specified any amount of bitcoins to transfer.
From what this may depend?

This is unrelated to Bitcoin itself. Bitpanda has a minimum withdrawal amount, and it seems that you do not have at least that amount to withdraw. The amount seems to be the equivalent of 100 USD (specifically, it is 0.002167 BTC at time of writing).
If you do in fact have more funds in your account than that amount, I would advise contacting Bitpanda for support.


What bytes are calculated on the transaction fee? I know that the bitcoin fee is calculated based on the number of bytes in a transaction (i.e. satoshi per byte). But what bytes are calculated? The bytes of the encoded/serialized transaction or of the raw transaction?

For example, I have the transaction below. The size of the raw bytes is 192. The encoded(hex) is  384. I used a fee of "1" satoshi to generate it so that I can get a sample of what the size will be like.
   Would be safe to multiple satoshi with the raw size to get the fee and then re-make the transaction? (e.g. 1000 satoshi * 192 = 192000 satoshi fee).

0100000001433a94862b051af03d6ad033153c937d258f6d501edc35a57b61b855f0b691b022ddb2126b483045022100da9bd107a96990429498df53d963a6b5d26455b180f3742f87c2352805d1bd33022033071d16a9578b765b38d68b51d692c575b9b3ce48e9b93276784e33adfd5a1201210342b992de6ebd9f2d0d522f9559d3ff6388fcdb70095c0f0dfe75811c74437bd1ffffffff01ae130000000000001976a914fafb913a62cce4c017e986d07d9a1c25d30e2ace88ac00000000

One hexadecimal digit represents 4 bits which is half of a byte (8 bits). Therefore, the raw byte length of a transaction is half of the length of its hexadecimal representation.

In your case, there are 384 hexadecimal digits, and the raw byte length of the transaction is 192 bytes. Depending on whether the fee rate is given in [satoshi/byte], [satoshi/kilobyte] or [BTC/kilobyte], you need to apply the corresponding unit conversions. Note that Bitcoin uses kilobyte here for 1,000 bytes.

There are two more pitfalls here:

Since the activation of segwit, fees are paid per weight, not raw byte length. In practice this means that transactions with segwit inputs require less fees than what would correspond to their raw byte length. I've explored the topic further here: Medium: PSA: Wrong fee rates on block explorers
Signatures in Bitcoin have a variable length. It is therefore common that your fee estimate is off by a byte or two, especially if your transaction has few inputs. You can get around that by either using a slightly conservative estimate (which is for example how this is addressed in Bitcoin Core), or by repeating the signature for the transaction until the size fits your estimate.


Physical bitcoin vs. Paper wallet? What is the main difference between a Physical bitcoin and  Paper wallet ?

And which one is more secure ? And why ?

A paper wallet is more secure than a physical coin with addresses, as the former you can make yourself, on your own machine, while with a physical bitcoin you never know under what conditions it was manufactured and who could have copied the keys.


How to specify number of threads for bitcoind? What field in config file or flag should I use to run bitcoind -daemon e.g. on 100 threads? Now I have 23 threads, but I want to increase this value.

$ ps aux | grep bitcoind
pavlovd+  1258  2.3  1.7 2682460 916020 ?      Ssl  Aug05  43:22 bitcoind -daemon
$ ps -o nlwp 1258
NLWP
  23

More threads will not make your software run faster.

Threads are used in order to be able to do more things concurrently, but not necessarily faster overall. Assume your internet connection allows you to download at 1 MiB/s, and you want to download 5 files of 200 MiB each. No matter what, you need to download 1000 MiB, which will take 1000 seconds. But you could choose to either download them one by one, or all concurrently. If you download them concurrently, they'll individually progress more slowly, but overall still finish at the same time.

Your CPU has a number of cores, and can typically run one or two threads on each core (See SMT). For computationally intensive tasks, it is therefore advisable to have as many threads as you have cores, in order to keep all cores busy. However, more is not helpful in making things faster. In fact, because of increased need for communication between threads, doing so may even reduce throughput. Bitcoin Core will automatically detect how many cores your system has, and create that number of threads for transaction and block validation. If you want, you can change this number using the par setting in bitcoin.conf.

Most of the threads you see are however not computationally intensive, and are in fact idling most of the time. They're just there to deal with occasional things that need to happen in the background and not interfere with other operations. That includes threads for sending and receiving network messages, for cleaning up database files, for interacting with the user (reacting when you click somewhere with your mouse if you use Bitcoin-Qt for example), or for responding to RPC commands. For the last one, there is a setting to control how many RPC commands can be processed in parallel, namely rpcthreads. Due to locking, only 1 or a few RPC commands can actually execute in parallel, however.

So, you can change the number of threads for some tasks, but that's rarely needed, as the defaults usually get you close to the best performance. If you want to make block synchronization go faster, the best approach is increasing the database cache size (dbcache) or running on faster storage (SSD helps a lot).


Possible to use an already generated bitcoin address? Back in June I was mining just to see what it was all about.  I grabbed bitcoin-qt, generated an address and put that address into the payout info of my account at the pool I was mining in.  I told it to send to my wallet for every .5 coins mined and during the time I let it run I managed to accumulate just over .5

I eventually quit running it, and sort of forgot about it.  I later formatted and re-installed, but I remembered my progress and backed up the folder containing my miner and my wallet.  Now it's Dec and my .5 coin is worth a bit of cash.  However I didn't export or back up my wallet, I just copied the folder.  Since there was no install routine I figured this was enough to preserve my addresses.

I still have the address I told it to send to and I can see the payout in the block chain and I see my address waiting for the payment.  Is there a way to put this address into my wallet or am I out of luck?

You're out of luck if you don't have the wallet, only the address. If anybody could take control of an address they don't have the private key of, the whole system is broken.


Is it possible to run a miner to confirm transactions for a target address? If I want to make a bitcoin transaction I need to wait 3-6 confirmations for my transaction to be accepted (by say an exchange etc)

Is it possible to run a miner so that it is listening out for transaction on my address, to have my transaction confirmed sooner?

Or at least have the first confirmation confirmed sooner?

(Plus would I be able to recoup some of the transaction fees?)

Yes, there are a few ways you can do this.

First, you could solo mine using GBT from Bitcoin-Qt, and prioritise your own transactions. But unless you find a block, this does no good.

Second, and perhaps easier, you could use a pool like Eligius which offers prioritisation as a perk to its miners.


Is the checksum used in BIP39 mnemonic sentences too short? In the BIP39 specification, you add 1 bit of checksum for every 32 bits of entropy you generate.

Therefore, with a common entropy size of 128 bits, you are only adding 4 bits of checksum. This means that if you were to write down the words in the mnemonic sentence in the wrong order (or write down an incorrect word from the wordlist), there is a 1 in 16 (0b1111) chance that a tool for validating your mnemonic will tell you that you have written down a valid mnemonic.

Is this too short to make checksums for mnemonic sentences reliable?

Alternatively, you could instead add 4 bits of checksum for every 32 bits, which would mean a mnemonic from 128 bits of entropy will have a 1 in 65535 (1 in 0b1111111111111111) chance of being valid if written down incorrectly. This would require a wordlist of 4096 words (12 bits per word) to accommodate the checksum and keep the mnemonic sentence the same length, but it seems that it would be much more reliable.

Is there a reason why BIP39 chose to use such small checksums?

Checksum in BIP-39 is mainly used for padding which may be the reason why smaller size checksums are used.
Each BIP-39 word represents 11-bits and in order to divide the entropy of an arbitrary size (which is normally a multiple of 8-bit such as 128, 160, 256,...) to 11-bit chunks it has to be padded first. For example in case of a 128-bit entropy 4-bits padding is needed (128+4=132%11=0) and that pad is the checksum.
BIP-39 authors may not have thought about recovery cases but if a bigger checksum were to be chosen it has to pad the total length to a multiple of 11. In case of 128 bits it needs to be 15-bits (128+15=143%11=0) or 26-bits, 37-bits,...


How private key is generated? I read here that:

  If you could process one trillion private keys per second, it would
  take more than one million times the age of the universe to count them
  all. Even worse, just enumerating these keys would consume more than
  the total energy output of the sun for 32 years.

However this website http://directory.io says that they generated all private keys. Who is right? or what is it that I misunderstand ?

And why this (from here)

  A private key is a 256-bit value, meaning there are approximately
  1.1579e77 possible keys (There are about 1.2288e66 invalid values...

They never claimed to have generated all private keys, only the ability to generate any possible private key.

The web site dynamically calculates a set of keys for a given page number. It does not store every possible key.

The web site cannot be used to discover a private key for a particular address because there is no way to search for an address.


Mimble Wimble chain privacy Does Mimble Wimble automatically perform transaction cut-through, or is one able to retain a record of every single transaction (the entire blockchain) if they choose to?

MimbleWimble isn't fully implemented, so this answer may change as implementations mature and we gain a greater understanding of the design space.

MimbleWimble transactions may be published to the network individually or combined with other transactions before being broadcast. For example, a user may choose to publish a new transaction on its own, or to mix the transaction in an off-chain mixer that will then publish it to the network.

However, it is my understanding that once transactions hit the network, nodes forward them as-is. This means that regardless of whether the particular MimbleWimble implementation allows it, an attacker can watch and record new transactions as they are broadcast. This would allow them to reconstruct a transaction graph, albeit one without addresses or amounts, just randomly distributed elliptic curve points.


Why do all Electrum master public keys all start with xpub661MyMwAqRbc? I was playing around generating wallets using the current version (2.6.4 on Mac OSX) and noticed that each new (standard) wallet I generated had the same start to the master public key: xpub661MyMwAqRbc. I noticed that this was also true in the Electrum documentation screenshots too: http://docs.electrum.org/en/latest/coldstorage.html Does anyone know why this is? Thanks in advance!

NB I posted this to https://www.reddit.com/r/Electrum too and will cross-post any answers I find on either forum :)

BIP32 specifies how hierarchical master public keys are serialized.

4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)

So, when a master public key is serialized, it always begins with 0488 B21E 0000 0000 0000 0000 00

Encoded, that's the pattern you see.


How is the USD price on Binance calculated since there is no USD involved in the whole exchange? I'm talking about this: https://i.imgur.com/wKP17oe.png
How is it calculated?

There are USDT markets in binance. If you are unaware, USDT is backed by USD and binance can use their own market's USDT value.


How is Public Key extracted from (message, digital signature, address) I'm under the impression that a public key is revealed when you sign a message.

Given these 3 inputs.
P2PKH Address, Digital Signature, Message.

Is the public key exposed?
If so, how do you extract the public key from these 3 inputs?

Also, I'm still a little confused on why no applications do this with bech32 addresses. (I've heard it's because derivation path isn't defined... but will it ever be)?

Thanks!

An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.

To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.

Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).

This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.

The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.


My system is syncing headers, what does that mean? My system got shut down while I was syncronising. Please help me, it's showing "Unknown. Syncing Headers" and estimated time is unknown.  What is happening here?

Bitcoin's state gets synchronized by everyone downloading the blockchain and applying all transactions in the correct order. Earlier versions of Bitcoin would just download block for block until they were caught up. Nowadays, Bitcoin first synchronizes only the block headers which are 80 bytes each and allow the node to pre-filter orphaned blocks and dead sidechains, before downloading all the corresponding blockchain data.

When your computer got shut down, likely some of your node's blockchain state got mixed up, so it's rebuilding the chainstate database, first headers, then blocks.


Does secp256k1 library provide API for generating uncompressed key? Hi I am right now want to do a make a small tool to generate some test vector for ecdsa.
Openssl is quite good, for support secp256k1 bitcoin provides an excellent library.

However, it looks what I get from secp256k1 API only the compressed key.
I find some post about how to convert the compressed key (Qx) to uncompressed key (Qx,Qy). But I just wondering if I can directly get the uncompressed key?

Thanks!

Use secp256k1_ec_pubkey_parse and secp256k1_ec_pubkey_serialize:

secp256k1_context *ctx = secp256k1_context_create(SECP256K1_CONTEXT_NONE);
secp256k1_pubkey pubkey;

const unsigned char input[33] = {0x02,0x8c,0x28,0xa9,0x7b,0xf8,0x29,0x8b,0xc0,0xd2,0x3d,0x8c,0x74,0x94,0x52,0xa3,0x2e,0x69,0x4b,0x65,0xe3,0x0a,0x94,0x72,0xa3,0x95,0x4a,0xb3,0x0f,0xe5,0x32,0x4c,0xaa};

if (secp256k1_ec_pubkey_parse(ctx, &pubkey, input, 33) != 1) {
    puts("Public key not on curve");
    secp256k1_context_destroy(ctx);
    return 1;
}

unsigned char outpubkey[65];
size_t written_bytes = 65;
secp256k1_ec_pubkey_serialize(ctx, outpubkey, &written_bytes, &pubkey, SECP256K1_EC_UNCOMPRESSED);

printf("Uncompress public key: ");

for (int i = 0; i < 65; i++) {
    printf("%.2x", (unsigned int) outpubkey[i]);
}

puts("");

secp256k1_context_destroy(ctx);


Are there actually merchant services for "outgoing" processing? I read this extremely informative QA:
My raw transaction destroyed 0.0284377 BTC. What did I do wrong?
For those of us new to the BTC universe, there can be confusion between BTC, exchanges, wallet service providers, BTC-related SAAS providers, and so on.
My question:

Notice that the OP in the question has some sort of business which both takes in and sends out BTC.

I mean to say, those operations are done automatically, by the www-based business in question.

Thus the business in question, has "some sort of software on a server", which, can both receive, and indeed send, BTC. So far so good.

What I am confused about:
it would seem to me that for such a common need, nobody would bother writing their own software to provide those two needs, because I assume, there are any number of large well-known services now which provide exactly that service?
(Obviously you might do it experimentally, or as the OP mentioned in the interesting question, it was done some years ago in the early days; or of course the largest enterprises might do it "from scratch". But surely normally there's just a service which does this via simple APIs?)
Thus, say I want to start a business called BitBall, which is a consignment warehouse for buying and selling baseball cards.  BitBall users ("type A") send in their baseball cards.  Other BitBall users ("type B") buy the baseball cards and they are shipped from the warehouse.
Obviously, "type B" users must spend BTC to BitBall, and "type A" users will have BTC paid to them from BitBall.
My question, it seems incredible that the BitBall programming team would have to program, from scratch, the BTC related software to enable type A receiving and type B spending ??
To repeat, my question is about an online operation which has to both send as well as receive BTC programmatically.
At first I just assumed the major services I had heard about (eg "coinbase") did this sort of thing but I was wrong. (I think!)
Again in short, surely there are (a number of? well-know?) let us say "merchant services companies" for the BTC universe, which handle both spending and receiving BTC?  For businesses (example - "BitBall") which both spend and receive?
Or really, do you just have to plain program it yourself from scratch?  Is there no such thing (yet?) as an in-and-out merchant services API service for BTC handling??

I was the OP of that last question that you referenced.

Tracking the 'receives' is actually very easy. There are plenty of free APIs (e.g.  BlockExplorer, BitPay/Insight) that'll let you check the status of your inbound BTC transactions with a single API call. It's really a no-brainer.

Sends, on the other hand, are harder to deal with. As opposed to a receive, whose status can be polled with a couple lines of code, a send requires signing using private keys and for obvious reasons, you don't want to broadcast your private keys through a public API. This is what led me down the path of building my own transactions programmatically.

Since the time I wrote that code, quite a few APIs have been made available. BlockCypher, for example, can assist you in building a binary transaction without requiring you to expose your private keys. Building binary transactions isn't exactly straight-forward though, even with an API. Could a person use one of these APIs to build a transaction without having some knowledge of crypto and the native transaction format? Yeah, perhaps, but still not a particularly pleasant process.

Remember, if all you're trying to do is accept Bitcoins for an online store or as payment for services rendered, there's absolutely no need to mess around with any of that low-level stuff that I referenced in my question. Just use a third party service like BitPay. They'll handle all the grunt work including invoicing, transaction building for customer refunds, etc. When I pay for my servers, domains, certs, etc. with BTC I don't think I've ever seen a vendor roll their own Bitcoin billing interface. It always goes through BitPay or a similar service.

My needs and business model are so unusual and specific that a standard package like Bitpay wouldn't work for me. For most use cases though, standard merchant services are the way to go.


Bitcoin client communication time constraints How long does the standard Bitcoin client wait between sending a message to another client and deciding that the client is not responding? That is, if someone makes a client that takes a couple seconds to write a response to a request, will it still work with the Bitcoin network?

Bitcoin client decides that the other client is not responding when it receives report from operation system that the connection is dead.

Bitcoin relies on OS implementation of TCP to send and receive messages. For example, by default, when connection was already established and Round Trip Time is known, Windows will try to resend data segment five times doubling wait time after each resend before reporting connection as dead. So the total wait time is: "Round Trip Time" * 2^(5-1) .

P.S. Timeouts are different for each type of message, e.g. total connection initiation timeout equals to 6 seconds .
TCP/IP Configuration Parameters


Is it possible to buy or sell Bitcoin options? Like put and call options for a stock, but for the future price of Bitcoin?

It is possible, there various sites that provide option (or option like) trading. Each have their pros and cons. Of the ones I know of theses seemed the best. However YMMV and caveat emptor.

At time of writing here are some simple ones:

btc oracle <-- Looks like a very elegant (bitcoin) solution. Just send some bitcoins to the addresses and if (in 15min, 3hr, 1day, 1week respectively later) you are in the money you are sent back X a Multiplier.
btc Levels <-- Similar to btc oracle in concept. Except you have to login to place your (high low positions) bets. Plus you can only place positions for up to the next 24 hr.

However neither of those let you buy/sell an option that is in the money(or out of), you have to wait until the option expires. And neither of them let you write options.

Some others:

icbit.se <-- Futures contract
mpex.co <--  Has a large buy in.
coinbr.com <-- They act as a broker to mpex.co (So has a much lower buy in)
1broker.com <-- CFD  for btc/USD
campbx.com <-- Options coming soon. (so is xmas though :P )


Can unupgraded nodes that accept zero confirmation be fooled after SegWit? Considering the following scenario:

  After deployment of SegWit, there remain two old clients (with software that is unaware of SegWit) A & B.
  A funds a transaction to pay B using a SegWit output which appears to both as ANYONE_CAN_SPEND.
  Upgraded nodes ignore this transaction, as it obviously isn't signed correctly under the rules of SegWit. (Perhaps even ban old nodes that relay this "invalid transaction" to them?) However, among old nodes the transaction gets propagated as valid.

In the case that B gets notice of the transaction, would it display an "incoming unconfirmed transaction"?
Could people get fooled that way if they accept Zero Confirmation (which I'm aware isn't safe)?

If it is a transaction that pays B, that means that B chose that address. If B doesn't support SegWit, it won't ask for a SegWit output, so this cannot happen.

In practice, SegWit wallets will likely use P2SH initially; the SegWit output will be embedded in a pay-to-scripthash, and the address a SegWit wallets gives to sender will be the P2SH hash of the SegWit output script. However, in our scenario, B doesn't know anything about all that, and will just give out a normal old-style pay-to-pubkey-hash address, and A will pay to that.

More information about failure scenarios around softforks that introduce new transaction types: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html


Transferring Money from China to another Country Using Bitcoin I would like to transfer large sum of money out of China to another country using bitcoin. China has a $50k limit on overseas transfer, so I thought bitcoin will be a good way to circumvent that.

How would I go about doing that?

Thanks in advance!

All you need to do is find someone to sell the amount you are looking for of bitcoins. After the bitcoins get to your address, you can spend them the way you like, anywhere in the globe (as long as you have internet access). So, if you wanna send them to someone abroad, all you need is get the bitcoin address of this person and transfer the amount you choose.

The main difficulty for you in China is, probably, find someone to sell the bitcoins in the first place. For that matter, you will have to do some searching in your local area.

Very simple!


Why does the banscore default to 100? What was the thought behind a banscore threshold of 100?  Why is that default, why not lower or higher?

In what legitimate circumstances would a node operator change the banscore for their node?

The concept of banscore is mostly historical at this point in time. The original concept was that minor misconfiguration or implementation wouldn't cause the whole network to disconnect itself instantly from one another. Small violations would just be counted towards their ban score, with large violations (like sending invalid block data) resulting in immediate maximum score.

Today most events which will cause an increase in ban score are going to reach 100 either instantly or very quickly, so it serves almost no purpose. You, as a node operator, get no value out of peers which are misbehaving, so there's no reason to change this value upwards. If the peer to peer logic was to be implemented today any protocol violation would just result in disconnection.


bitcoin-cli failed with error: incorrect rpcuser or rpcpassword When I run this command

bitcoind -testnet -printtoconsole -rpcuser=123456 -rpcpassword=123456

After bitcoind is up. I run this on the same Ubuntu 17.10

bitcoin-cli -testnet -rpcuser=123456 -rpcpassword=123456 getbalance

I get this result:
error: incorrect rpcuser or rpcpassword (authorization failed)
The second day I tried exactly the same way. I get the correct result. It is really weird.

I try to put these two lines in /home/user/.bitcoin/bitcoin.conf

rpcuser=123456
rpcpassword=123456

And I run this command

bitcoind -testnet -printtoconsole -conf=/home/gogogo237/.bitcoin/bitcoin.conf

And this

bitcoin-cli -testnet -rpcuser=123456 -rpcpassword=1234564 getbalance

notice that I intentionally changed -rpcpassword to a wrong password. But I still can get a correct result.
This is really unpredictable and obviously a mistake. Anyone can explain this error? Thanks!

re-compiled on an Ubuntu system, fresh from github.com:

$ uname -a
Linux ubuntu-ae 4.10.0-19-generic

$ bitcoind -version
Bitcoin Core Daemon version v0.15.99.0-g96ac26e5662

$ bitcoind -testnet -printtoconsole -rpcuser=123456 -rpcpassword=123456

$ bitcoin-cli -testnet -rpcuser=123456 -rpcpassword=123456 getaccountaddress "myaccount"
n2r1aQiA37LLgy4qWjuLHXqA9ZhtcX4KG6

$ bitcoin-cli -testnet -rpcuser=123456 -rpcpassword=123456 getbalance
0.00000000

and with wrong password:

$ bitcoin-cli -testnet -rpcuser=123456 -rpcpassword=1234564 getbalance
error: incorrect rpcuser or rpcpassword (authorization failed)

so s.th. is wrong with the sources? Or with Ubuntu setup. What kernel do you have (uname -a) ?


Building an blockchain address monitoring service. Best way to monitor an address for bitcoin and other altcoins? I'm looking to build a blockchain address monitoring service for bitcoin and other altcoins. What is the best way to monitor a bunch of addresses for incoming/outgoing transactions?

Currently I wrote a php script that checks the address every 5 minutes for any new activity and then store this data to a file and then another 5 minutes I fetch the data again and diff the file to see any differences and if so do something.

Another method I was thinking was to fetch each block as its mined then see if any of the addresses match what I have listed then do something.

Since you mentioned PHP you can install a Bitcoin Node on your server and then use EasyBitcoin-PHP: https://github.com/aceat64/EasyBitcoin-PHP

Then use the Bitcoin API:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

To list all transactions associated with an account:

echo $bitcoin->getreceivedbyaddress($btc_address);

"Returns the amount received by  in transactions with at least [minconf] confirmations. It correctly handles the case where someone has sent to the address in multiple transactions. Keep in mind that addresses are only ever used for receiving transactions. Works only for addresses in the local wallet, external addresses will always show 0."

So you could run this and compare with your DB to see if a new transaction appears that isn't already in the DB.

--

To monitor a balance of an account you can just check on each page load (and update your DB if you wanted to):

echo $bitcoin->getbalance($user['id'], 1);

Get one of your users addresses:

echo $bitcoin->getaccount($user['id']);

To check transactions:

echo $bitcoin->gettransaction($trans_id);

--

You could also use an API:
How to get the list of transactions of input/outputs for a bitcoin address in JSON format?

--

I'm not 100% sure what you're asking for but I hope what I provide helps you.


Export Private Keys from Bitcoin-QT I am still attempting to complete the receipt of a payment in BitCoin-QT. The initial synchronization is beginning to be a hassle so I thought I might get my key and transfer my wallet to Blockchain.info.

I followed the directions in How do I export my private keys from my Bitcoin-QT?
to get my private key. All I get back for dumpprivkey[] is:

  Invalid Bitcoin address (code -5).

I thought maybe I had the wrong address so I entered listreceivedbyaddress 0 true.

There are only a couple of addresses since I have a new wallet. All of the addresses returned the same "Invalid Bitcoin address" message. What is going on? I know one of these addresses was used to give to an exchange for my new BC. Is it simply because my blockchain is incomplete and the transaction is incomplete?

My solution to the question for an encrypted wallet:

walletpassphrase "......." 600
dumpprivkey ......

I made the mistake of including the brackets [ ] when entering the public key after the call dumpprivkey.


Withdrawal transaction made 8 hours ago still has not had any confirmations I made a deposit into a bitcoin exchange on 2018-09-11 06:57:41. The exchange then made a withdrawal transaction on 2018-09-11 13:19.

The time is now 2018-09-11 21:55 but the transaction still has not had any confirmations. The mempool size is currently 12 Mb which should not be large enough to cause such a delay.

The output for the withdrawal is a bech32 address. Has anyone else seen delays in withdrawal transactions, possibly to do with different address formats on the output?

https://blockchair.com/bitcoin/transaction/946d199348cdd21209e1c42f8df1700be9a238bb220d7e03ceff5b136e7cca2b

Thanks

That transaction is 90 KB in size; presumably the exchange is aggregating deposit transactions from many customers.  And its fee is about 1.3 satoshis per byte.  As you can see here, there are currently lots of outstanding transactions offering a higher fee rate; as such, a miner would likely prefer to confirm 90 KB worth of smaller and more lucrative transactions, rather than this one.

The output address type doesn't have any direct effect on confirmation time or miner preference, as far as I know.

The size of the mempool in MB is not a particularly useful statistic in estimating confirmation time (until it gets below the block size, at which point you would roughly expect that the next block will confirm everything).  Transactions don't get confirmed first-come-first-served; a low-fee transaction can languish indefinitely as long as more higher-fee transactions continue to arrive and be given priority.

Note that as a customer, this is not your problem.  Your job was done once your deposit transaction was confirmed, and the exchange should have credited your account at that point.   What they do with the money after that is solely their concern.  It's quite possible that they've intentionally lowballed the fee.  If a lull in transactions occurs sometime soon, maybe they get lucky and it confirms at this low fee.  Maybe they don't care whether this happens anytime soon; after all, it's probably just money moving around inside their organization.  If at some point it becomes more urgent, they can offer a higher fee (e.g. using RBF or CPFP).  But none of that is any concern of yours.


How is the next forger decided in Nxt? I've read both the Nxt whitepaper and many other resources on the wiki but I still can't seem to understand how exactly the forging process works. From what I understand, there are a bunch of online users with their account "unlocked" (so they can sign the next block if they win). I don't understand how the winner (or the next forger) is decided. Is it random, or is it based on how many nxt coins one has?

For example let's imagine there are three users online with their accounts "unlocked": Alice (has 40 nxt), Bob (has 55 nxt) and Fred (has 13 nxt). The wiki says:

  Your probability of forging a block depends on your share of the total
  number of coins that are active on the network.

If that's true, wouldn't Bob (who has more coins than Alice and Fred) win the block generation every time? But then how is it possible that even accounts with little coins are still able to win at forging? Does it have something to do with the fact that the winning forger has to wait 1440 blocks before they can forge again? Is this what gives a "chance" to the less-rich users to win sometimes?

Also, if Bob is winning every time, couldn't he just go back the last 10 blocks or so and replace them with different blocks?

Which account is entitled to forge the next block depends on several things.

The last block added to the blockchain includes a 32-byte "generation signature" (actually a hash). This signature is concatenated with the public key of each account attempting to forge the next block, then sha256 hashed to produce a new generation signature to be included in the next block, the block currently being forged. The 8 most significant bytes of the new signature are combined into a 64-bit integer in reverse order (little endian) to determine the "hit" value of each account.

These hit values are effectively random and can't be known before the latest block is added to the blockchain, but after that they are known throughout the network. Any account receiving a newly forged block from the network can verify that the generating (forging) account is eligible to forge, because it knows the last block's generation signature and the public key of the forger, both of which are included in the new block, and thus can compute the hit value for any account.

Because the hit value is effectively random, every account with a non-zero EffectiveBalance has a chance to forge. A low hit value is desirable, because then even an account with a low balance can get a hit. The formula for getting a hit is

hit < BaseTarget * EffectiveBalance * TimeSinceLastBlock

The BaseTarget is dynamically adjusted with each new block so that a hit occurs somewhere on the network about once per minute. A hit will eventually occur even if the hit value is by chance very high, because it becomes easier to get a hit with each passing second because of the TimeSinceLastBlock (in seconds) term.


Create alternative blockchain with proof-of-work For learning purposes, I want to create an alternative special-purpose blockchain. It would use a proof-of-work function that is different than the one in Bitcoin.

Short of forking bitcoin and going from there, where should I look into starting?

The data that the blockchain would be storing are public keys.

Bitcoin wiki: https://en.bitcoin.it/wiki/Alternative_chain

What you're asking to do here is actually the definition of forking bitcoin.
Short of doing this yourself in code, there are services such as http://coincreator.net/ that will accomplish your goal. CoinCreator allows for you to pick your proof-of-work function from a set of predefined functions.

Good Luck!


How to connect existing MEW to Trezor? I have got my new Trezor but I don't know how to connect my existing myetherwallet to trezor ether address ?

Is there any way I can directly import and connect to trezor ?
Or I have to create a new myetherwallet with trezor and transfer ethereum and other erc20 coins from old myetherwallet to new ether trezor address ?

You cannot import your existing MEW to Trezor wallet.

It is the security of a hardware wallet which makes it worth the price, and that is why the wallet is generated in Trezor offline.

Thus, the only way is to create a new wallet in Trezor. Transfer all your coins from existing MEW to Trezor. And after that, you can use Trezor with MEW to send or receive other alt coins which Trezor don't have support directly.

Hope this answers your query.


How much of bitcoin core software can be custom written at miner's end and how much of the code you can't touch? where does bitcoin draw the line? I've read bitcoin content everywhere on the internet and nobody has yet demystified the fact that different versions of bitcoin core are working simultaneously. I know how soft forks work and how they are backward compatible and the don't break consensus. But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or It can't be custom-written?

Please explain in terms of powerful solo miners and pool miners.

Forget Bitcoin for a second, instead imagine a network of nodes that passes around data packets that say Hello World!, followed by the current GMT date. To be a part of the network you just need to transmit such messages, but transmitting a different or improperly formatted message will get you banned.

So to join this network, all you need to do is to write a simple program that creates a message which reads Hello World!, and then the date. The choice of programming language doesn't matter much, neither does the method of discerning what the date is. Even the most newbie developer could write a program that would successfully maintain a position in the network, as long as they follow the rules.

Notice that in this example, what matters is the output, not how we arrived at it.

Back to the bitcoin network:

  But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or it can't be custom-written?

All of it can be custom written. On the bitcoin network there are many different versions of bitcoin-core running, as well as some other full-node implementations such as btcd or bitcoin-knots. For mining it is the same. Each different implementation can be an entirely different codebase, written in a different language, by different developers. What is important is the output of that codebase:

For bitcoin full-nodes, the desired outcome is that the node will stay in consensus with all other nodes about the current state of the network. Broadly speaking, this means following along with all 'consensus rules'.

For miners, the desired outcome is that they will be working to create what the network of full nodes will view as a valid block. A new block must conform to many rules in order to be seen as valid, so again the implementation's output will obviously have to respect those rules. Note that a miner will need to be running a full node to do so, in addition to running some code that actually constructs and hashes block candidates.

Pragmatically speaking, it is much easier to write a custom miner implementation, as there are less rules that must be strictly followed to achieve the desired outcome (ignoring the dependancy on a full node for network status information, of course).

Note that there is no way to check or enforce that other nodes on the network are running some specific code, even if you asked, they could just give a false answer. What does matter is the ability of those nodes to all stay in consensus - it is perhaps easier to maintain this if all nodes are running the same codebase, but it is not strictly necessary.


Send download link of a file after Bitcoin payment I'm starting an online business. My website is hosted on OVH I would like to send a download link after a bitcoin payment.

Are there specific stuffs I should be aware of?
Is this difficult to develop? (I have a bit of experience with JS, JAVA HTML/CSS) but I don't really knwow where to start with the GET... commands.
Is it safe to store the file directly on my FTP?
Do external websites already provide this kind of services (payment and download)?
What could be the best language to use with the blockchain api?

just to be more specific:

the scheme of the whole think would be:

user: I'm interested in your product.
server: Please pay for it with your bitcoins.
user: I'll do that I'll go on your dedicated page.
server: Ok we received your payment you just received a link for you to download our file.
user: thanks it worked!!!

your help is appreciated many thanks in advance,

You do not need to deal directly with the blockchain. The answer is:
Payment Gateways
There are services called Payment Gateways that encapsulate the entire invoicing/payment process and allow you to check on the status of each payment (manually or programmatically) to offer your goods.
One such example for bitcoin is Bitpay. Bitpay provides you with a RESTful API which you can call/query for information retrieval and/or for the execution of specific orders/transactions. You can find all the details in this API reference
As far as the implementation goes, Bitpay provides you with numerous clients in different programming/scripting languages, namely: PHP, python, Node.js, Ruby, Java, C# etc...
There are many bitcoin payment gateways available with different offerings and pricing schemes. Do some research to find the one most suitable for your budget and task.
Is it difficult to accomplish? Not necessarily. However, this is highly dependent on your level of skill and knowledge in programming specifically web development.
I would also recommend you hire a specialist to do this for you if your grip on security is not so well, since security is one of the major concerns when dealing with financial transactions.


How does one create a brain wallet from a seed using SHA256? How does one create a brain wallet from a seed using SHA256? Is this possible?

Could you please explain using the example seed "coinbase is awesome" (no apostrophes)? What is the resulting address?

A bitcoin generator can generate an address.

i.e. https://brainwalletx.github.io/


How to connect two bitcoin nodes running globally I have two nodes running in different PC-s they have different IP-s. I want to connect one node to another with -addnode or -connect arguments. Can anyone help me please?

It seems like you answered your own question? You can use addnode=IP if you want to connect to a specific node as well as others, or connect=IP if you only want to connect to that one node and no others. Just add it to your configuration file.


Given that contracts can be formed in the blockchain using scripts, couldn't a contract include a mechanism for facilitating chargebacks? While I understand that chargebacks, or the lack thereof are an important feature for encouraging merchants to adopt bitcoin, the reverse may be true for consumers.

There is probably a balance to be found, but is such a thing even possible?

You could use 2-of-3 outputs to do this, where the third key is held by a trusted mediator.

A merchant could consider himself paid when the 2-of-3 transaction is confirmed. In the normal course of events the 'chargeback period' would expire and the mediator and merchant would send the money to the merchant's normal address.

If the customer requests a chargeback before that, then either the merchant would agree or the mediator would step in and perform the chargeback according to whatever policies it sets.


Why I have some many address when I only created two wallet address in Electrum? I am new to this. I have created two new wallet addresses (labeled init and init2). However, when I click "View > Show Addresses," I found a lot of addresses.
Why?
What do receiving and change mean on the Type column?
Can somebody help?

Electrum will generate a certain number of addresses in advance. It doesn't really matter since it will always generate the same addresses in the same order thanks to using Hierarchical Deterministic (HD) wallet, but you can modify the number of addresses generated if you want, it's called the gap I think.
The gap can sometimes matter though if you're using some software like Electrum Personal Server or BTCPay, if you received a payment on an address that is outside of your gap (for example, Electrum only generates 20 addresses and you've got a payment on the 34th), Electrum won't see this payment and it can make you believe it's not there. If it ever happens, relax and augment the gap until you find all your payments.
receiving are the addresses you will use to receive payments, change addresses are automatically used by the wallet when you spend bitcoins to send your change to. In theory nothing prevents you to directly send bitcoins to your change address (I mean those addresses have nothing special from a protocol point of view), but it's pointless and bad practice don't do that.


Anatomy of mixing transactions I've read some literature on mixing in systems like TOR and also in Bitcoin.
In Bitcoin and Cryptocurrency Technologies, the authors explain that uniform transactions are highly important in order to prevent correlation attacks by matching inputs and outputs:

  Uniform transactions. If mix transactions by different users had
  different quantities of bitcoins, then mixing wouldn’t be very
  effective. Since the value going into the mix and coming out of a mix
  would have to be preserved, it will enable linking a user’s coins as
  they flow through the mix, or at least greatly diminish the size of
  the anonymity set. Instead, we want mix transactions to be uniform in
  value so that linkability is minimized. All mixes should agree on a
  standard chunk size...

However, I'm unable to find examples where this is visible in the blockchain.

I've also seen mixing in Bitcoin described differently, for example in the Bitcoin and Beyond paper:

  The mixing service aggregates bitcoins received from all its users to
  re-distribute them again. Some services use randomness, i. e., they
  split the amount into smaller random chunks and transfer them after
  random intervals. The user can schedule the transactions and provide
  time constraints.

Now I'm looking for examples of these types of mixing transactions in the blockchain, especially one where I can see a fixed chunk size being used.
Is one of these schemes used more frequently nowadays?

Is the second scheme really secure? If THIS is actually mixing like I assume, then isn't it possible to match sets of inputs to sets of outputs that have the amount (or slightly less) BTC value and therefore have to be connected? I can imagine that this does also work over the course of multiple transaction in case the payout of a mixer is split into intervals.

As I see it, the techniques you are referring to are two possible but different ways of doing mixing. The first one, explained in Bitcoin and Cryptocurrency Technologies book is referring to a kind of mixing technique like CoinJoin.

CoinJoin is a mixing technique in which several users create a transaction by joining their inputs. In order to maintain their privacy, all inputs should share the same value, since in that way once the transaction is created there is no way of telling which input correspond to each output, whereas if the inputs hold different value it will be way more straight-forward. There are to ways of implementing a CoinJoin scheme, the first and more simple one relays in a third party receiving all inputs, outputs and signatures, and building the transaction from the participants. The other one, more elaborated, does not need any third party, since every user acts as a blind-signing server.

On the other hand, the technique referred in the Bitcoin and Beyond paper uses a mixing server, which acts as a trusted third party, where users will send funds and eventually receive them back in a different address (after applying a certain mixing fee). In order to avoid linkability between received and sent transactions, this kind of mixing technique uses randomized delays to redistribute transactions. blockchain.info's Send Shared, and bitmixer.io used to be examples of such a mixing technique.

Finally, regarding examples of such transactions, unfortunately I don´t have any particular CoinJoin transaction identified to let you know, maybe someone else can help you with that.


Why is my bitcoin node not picking up transactions? Im running a very simple bitcoin core node that talks to a client. Whilst running on the testnet everythign works perfectly. As soon as I switch to live, the bitcoin node no longer seems to pickup transactions for payments into addresses it generates. I double checked the payments with blockchain.info and the payments were received and confirmed. Anyone know what is going here?

bitcoin.conf

prune=600
maxconnections=10
rpcthreads=2
rpcuser=#######################
rpcpassword=#############################
daemon=1
keypool=10000
walletnotify=############################
blocknotify=##########################
testnet=0
rpcallow=###############

The same config and was used for test/live with the obvious exception of toggling the testnet value.

Turns out the issue was that Bitcoin core had not finished downloading all blocks. It was running extremely slow. After allowing more connections everything sorted itself out overnight.


Electrum exchange rates. Where do they come from and why are they incorrect? On the simple view on the Electrum client, the value of the bitcoins is displayed in USD, GBP and EUR (changeable by clicking on it).

Currently by clicking through, I am seeing exchange rates:

10.29GBP/BTC
10.40EUR/BTC
11.90USD/BTC

This is completely out of line with mtgox, and also completely out of line with international currency markets (currently 1.6usd/gbp and 1.24eur/gbp)

So could someone explain where these rates come from and why they are so incorrect?

As of this writing, Electrum retrieves its exchange rate from Intersango. The last sale there must have been abnormally low for the current exchange rate.


How to create block height to UNIX time converter? I want to create a converter that can be given a block height, human readable time, or UNIX time and then provide the correlated information for it. For example, if given a block height, the converter will give you an estimated time (UNIX and converted to human readable format). And the same if given a UNIX time, it'll provide block height and human readable time associated with that block. And so forth if given a human readable string (stretch goal).

However, looking at the information online it seems pretty lack luster and also very approximate, using formulas, etc. See links here of similar questions:

https://ethereum.stackexchange.com/questions/10576/calculate-approximative-block-height-at-a-certain-time

https://www.reddit.com/r/BitcoinBeginners/comments/87lr89/is_there_any_block_height_to_datetime_converter

Are there any methods that could be achieved to create a deterministic result?

One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

In theory there is one block per 10 minutes. That means you should be able to approximate the time of a block n as FIRST_BLOCK_TIME + n*600, where FIRST_BLOCK_TIME is the time of the genesis block, 1231006505.

Of course, that's very approximate, as the average time per block has been consistently less than ten minutes due to increasing block difficulty. In fact, as of writing (block 622719 with timestamp 1585016395), is 19621510 seconds earlier (over 7 months) than what would be predicted by that formula.

  One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

Using the real data is obviously going to be better than any approximating formula. Note that the timestamp of blocks are not necessary the actual time they are mined (in normal circumstances they can be up to 2 hours in the future, and up to approximately 1 hour in the past).


Is Bitcoin's supply inflated by the exchanges of Bitcoin? For example, would an exchange of Bitcoin hold accounts for 100,000 customers, and they collective have 8000 bitcoins, but the exchange itself does not hold 8000 bitcoin, but only 1600 for customers to redeem (to transfer to their own wallet if they want to), and therefore, inflating the bitcoin supply by 6400 bitcoins?

It's certainly happened before when there was less regulation or among the smaller, less-regulated exchanges. Whenever an exchange disables withdrawals for everyone, it could be due to them running into liquidity issues like that.
Large exchanges are now regulated by various money services authorities in part to prevent this exact scenario.


How to create a tx that cannot be replayed? I've got a very precise question about (self-)protection vs replay attacks in Bitcoin but to clearly explain myself, I need to explain what I did with Ethereum.

When the Ethereum fork happened (ETH / ETC) I did split my ETH / ETC myself.  At first I failed (my tx got replayed on both chains, but I was in control of all the addresses, including the destination address) and then I did it like this:

I had 2500 ETH pre-fork on a single address, so post post fork I had 2500 ETH and 2500 ETC.
sent 5 ETHs on the ETH chain only
Move 2505 ETHs to an ETH-only wallet
Move 2500 ETC to an ETC-only wallet

My thinking was that the tx to move 2505 ETH on the ETH chain wouldn't be replayable (because on the ETC chain I had only 2500 ETC, not 2505 ETC) and, surely enough, this time it worked.

I know that there were other ways to achieve the same result but that's how I choosed to do it because I really liked the idea of creating a tx that wouldn't be valid on the other chain.

However I'm not familiar enough with Bitcoin and UTXO and what precisely makes a tx nor how it is signed to understand how this would work under Bitcoin.

If there's one (or several) hard fork, can I use the same technique to "split the BTCs" myself?

For example if I have 80 BTC on a hierarchical deterministic wallet (Ledger Nano S in my case), can I send 0.1 BTC there, then move 80.1 BTC and be sure this movement of 80.1 BTC is not going to be replayable on the fork where I still only have 80 BTC?

Would that work?

Note that this question is not: "How do I split my coins in case of a hardfork?" but "Would this particular method of splitting work on Bitcoin too, just liked it worked for me on Ethereum?"

Yes, that method would work. It only works if the 0.1 BTC that you use as taint was mined after the fork. If it was from before the fork, then the transactions can still be replayed.


Need help to recover blpckchain.info wallet, my wife forgot her password and the brute force with btcrecover is not catching the password I used btcrecover to extract the wallet file (wallet.aes.json) from a blockchain account and I have been running btcrecover with dictionaries of my making but it has been going on for weeks and I am running out of ideas on how to permutate what my wife and I think the password could have been.  Is there a way to just manually transfer the btc from the old wallet into a new wallet we do have access to or is there any way to extract the password or private keys directly from the wallet file?

We have: the phone with the original wallet app installed, the wallet file pulled using btcrecover, access to the email to allow authorization to access, the wallet identifier that was sent to her email when she first signed up, the phone which has the wallet, the pin that was used for the wallet, and we know how much btc is in the account.

We do not have: The private keys, a backup file downloaded from the blockchain api, a recovery phrase (it was never set-up), 2fa enabled on the account, access to the wallet file on the phone (as the phone was not previously rooted and the files are hidden somehow).

I had a blockchain wallet on my phone and when I knew I was going to switch phones I had my wife make a wallet on her phone in advance so I could keep our btc in her wallet during my transition.

The day came and I transferred the btc to her phone. It made her feel special to have it on her phone so I let her keep it there for a while....until I needed it to make a purchase with a visa card I have linked to another account and I took her phone and used the pin to unlock it except....it didn't unlock. I was sure I was using the right pin because it was the same one she always uses but thought perhaps I just mistyped something. I tried a total of three times and then it said I was locked.....that was annoying so I brought the phone back to my wife to open it with her password and she said she used a different pin this time to be more safe but that she didn't remember which password she had used to set it up.....

we tried numerous different passwords manually with no success and then we reached out to the blockchain wallet customer support with a back and forth conversation that ultimately led to them saying they can not help and we should just keep trying passwords.

I have worked with a few friends tried have so far been able to successfully use btcrecover on a test wallet to download a wallet file and then use the brute force features on a dictionary file to discover the password (which is easy because I already know that password).

But now that I am trying it on my wife's wallet the dictionaries were taking too long so I rented virtual computers online which are faster than my own pc and then I was returned with "password search exhausted" now I am trying new dictionaries but I am worried that we may not get it.  the more wildcards I put in the dictionary the longer it takes....

Also pywallet does not seem to be able to read the wallet file that comes from the blockchain wallet. I couldn't get it to work on any of my test wallets and so I have never tried that program with my wife's wallet.

Can anyone help!?

Is there a way to just manually transfer the btc from the old wallet into a new wallet we do have access to

No.
You need at least one of the things you have none of

working wallet.
PIN or password for the wallet.
Recovery phrase for the wallet.

is there any way to extract the password or private keys directly from the wallet file?

No.
The brute-force guessing method you are using is the primary known method.
There have been alleged security vulnerabilities in the blockchain.info wallet but it is possible your wallets were patched to fix those issues. It may be a long shot:

Major Wallet Vulnerability Revealed As User Barely Reclaims 9 BTC
blockchain.info vulnerability allows attackers to steal bitcoin wallet backups

Can anyone help!?

No,
You are already doing the right thing I think.
Unfortunately, from the perspective of the software designers, what you are doing is exactly what they must make every effort  to prevent being possible. If you could easily do this, so could a hacker or someone who stole your phone.

Footnote. OP knows this - but it is a good idea to remind new readers:
The Blockchain.info website says

Your Backup Phrase is made up of 12 random words, and is an encoded version of your master seed (and an industry standard). It acts as a backup and allows you to access your bitcoins and ether regardless of the wallet software you’re using. In the event that you lose your password, or choose to use another wallet provider, your Backup Phrase is all you need to regain access to your funds.
Quick tip: You can find your 12 word Backup Phrase in your Security Center after creating your wallet. Write this phrase down and keep it somewhere safe.

(my emphasis)
I'd go further, practice wallet recovery and make sure you can recover a lost wallet before putting serious money "in" it.


Is this calculation of mining probability using the Bernoulli trial formula accurate? I'm trying to understand the formulas for successfully mining a block (without a pool) based on hashrate over time (i.e. to chart the probability of finding a block at various historical points compared to network hashrate at the time).

It seems like this post is exactly the formula I'm looking for, but it doesn't actually add up. I'm awful at math so I can't tell if I'm missing a step or if the post is wrong. If there's a better/more accurate way of figuring this out, please share, but I'm specifically interested in learning if this is wrong or not and why.

It says the probability of being the one to successfully mine a block with 13.5 TH/s and a network hashrate of 11,000,000 TH/s = 0.00000122

Then it says:

  Now, in a month, there are N=6*24*30 mined blocks. To find the probability of winning one award in a month, we use the Bernoulli trial formula

  N*p1*(1-p1)^(N-1) = 0.0026

Now when I put that in Excel with N=4320, I get .005243, I only come up with the same answer when I divide N by two for N=2160, but I can't figure out any reason for that to be the case. Am I missing something or is this just a typo? Is this formula even a good way of approximating this?

The formula is a reasonable approximation.  It looks to me like your calculation is right, and the blog author has made an error.

There is a minor inaccuracy in that the number of blocks per month is not fixed at 6*24*30, but is subject to random variation.  So a slightly improved solution is to work out the average number of terahashes needed for one block (h = 11000000 * 600, assuming that the network hash rate is stable and the block difficulty has adjusted accordingly).  Then your probability of winning a block on each of your hashes is q1 = 1 / h, and you will perform M = 12.5 * 60 * 60 * 24 * 30 hashes in one month.  If you treat the number of blocks you win as a Poisson distribution, the probability of winning one block in a month is given by λ * exp(-λ) where λ = M*q1.  This yields the slightly larger number 0.005273.


Bitcoin Core HD Wallet v0.13.2 missing confirmed incoming transaction I made a transaction from my android wallet to my bitcoin core HD wallet (v0.13.2). At the time of writing, the transaction has 5 confirmations, both according to the android wallet and blockchain.info. However, my bitcoin core wallet fails to pick up the transaction, despite showing the right blockchain height.

The recipient address was generated by bitcoin-qt, hence it does belong to my HD wallet. Furthemore, I am able to sign a message with this address on bitcoin-qt (indicating I own the private key) and successfully verify the signature. In fact, in the course of my investigation, I had the unpleasant surprise of realizing that this address had already been generated in the past and I had already sent bitcoin to it as can be seen here. (This seems related to the issue reported in this post but is no longer the most pressing matter now). The older transaction using this address is part of my bitcoin-qt transaction log. So there can be no doubt the recipient address does belong to my bitcoin core HD wallet.

I am reluctant to attempt replicating the issue I have just described with another trial transaction. However, as this is probably relevant, I will explain what I did prior to this happening: 1. I made a copy of wallet.dat and removed the file from ~/.bitcoin (so running bitcoind or bitcoin-qt would automatically generate a new emptywallet.dat). 2. prior to the transaction I restored my copy of wallet.dat into ~/.bitcoin and started bitcoin-qt. 3. I asked bitcoin-qt for a new address and had my android wallet carry out the transaction. 4. I then shredded and removed wallet.dat and restarted bitcoind for a while. 5. When seeing the transaction had been confirmed, I re-instated my copy of wallet.dat into ~/.bitcoin with the intention of performing another transaction. 6. I then re-started bitcoin-qt which fails to pick up the latest transaction.

Note that this process of mine of shredding wallet.dat from ~/.bitcoin (while a copy of the file exists in a more secure location) is something I have just decided to do, as a way of making it harder for any potential hacker to spend the coins on this wallet.

So my bitcoin core wallet is obviously confused. Is there anything I can do to set it straight?

EDIT: When I re-instated my wallet.datinto ~/.bitcoin I am guessing a re-scan was not triggered for some reason. I shredded again my current wallet.dat and re-instated my (older) backup: this time a re-scan was triggered and the missing transaction was picked up.

So this issue is resolved as far as I can see it (albeit with the unease of not knowing why).

Bitcoin Core currently has no internal function to recover a complete wallet. If the key is unknown (not generated yet), Bitcoin-Core will not detect transaction from to to that key/address. Also, the keypool size does not matter at this point, funds sent to a keypool key/address are not detected at the moment.

For now (Bitcoin Core <= 0.14.0), if you restore a backup, make sure you generate plenty of addresses, loop through getnewaddress and ensure you generate 1000 (or more?) keys.

After you did this, restart Bitcoin Core (qt/d) with -rescan

Hopefully we can add some HD restore features for Core 0.15.


Is the Lightning network a proof-of-stake system? In his recent talk, Andreas Antonopoulos said "By probably the end of 2016, Bitcoin will have a hybrid proof-of-work/proof-of-stake system." and then continues to label the Lightning network as a POS system.

Is the Lightning network a proof-of-stake system?

Calling Lightning a Proof-of-Stake system is orthogonal to the concept usually labeled as PoS. Him having done so will just generate loads of confusion.

What we usually describe as PoS is a mechanism to achieve distributed consensus among a network of participants. Staking there is providing updates to the whole network's state, where you earn fees for contributing to the validity and the security of the network.

On the other hand, Lightning Network is a system of bilateral smartcontracts, where you may earn a fee by providing liquidity to other users. Nodes along a payment path don't provide any proof whatsoever, they merely forward a payment. There is no global consensus in Lightning, contracts are created, verified, and executed between two or a small number of participants. Any need to create consensus in the case of disagreement is provided by the proof-of-work of the Bitcoin network.


Why does the blockchain keep transaction history rather than balance? The blockchain is very large and takes a lot of time to download to a client. Apparently, the only thing we need from the blockchain is the balance of each "user" (- public key). So, instead of keeping the entire blockchain, we could keep a smaller ledger that only contains the balances. Why isn't this done? What are the advantages of keeping the entire sequence of transactions?

Keeping the entire transaction history allows us to independently verify that everyone's balances (note that Bitcoin does not actually use accounts or balances) are correct. Without having the full transaction history, we cannot verify whether someone actually had the money; the only way to do so is to follow the trail of transactions all the way back to the creation of a coin and check that all of those transactions are valid.


How profitable was GPU mining in 2011-12? I am not interested in mining myself, I just want to know how true my friend's claims are since Bitcoin is a subject that I try to follow and understand.

He says he mined 31 bitcoins in 7 months using 2 gtx 460 in a regular gaming PC. This supposedly happened around 2011-2012. I told him this sounded like too much to me and he says it was possible because he was in a "hard to access" mining pool.

So, I just want to know if these numbers are remotely possible. My limited knowledge and the browsing I have done says it's too much but, of course, I could be wrong.

What do you guys think? Thanks.

Question in title: similar to how profitable it is now.

The numbers he is giving you don't seem unlikely. Using the Bitcoin price of those days he probably could have gotten more Bitcoins than 31 by simply straight up buying them instead of the graphics cards. And if he accurately accounts for the electricity costs it was probably not profitable at all.

His luck (and the reason you are asking this question now) came when the price of Bitcoin went up.

  because he was in a "hard to access" mining pool.

That sounds like a bit of a misunderstanding tbh.


Can I send bitcoin to other address in my wallet to provide anonymity? I want to buy service Z.

I have 2 addresses in my bitcoin wallet: aaa and bbb.

I buy 1 bitcoin from coinbase and tell coinbase to send them to aaa.

Now I send them from aaa to bbb. No one else knows that bbb is also in my wallet.

I buy service Z by sending my bitcoin from bbb to Zwallet.

I'm safe. Yes? Safe ish? Not safe at all? Dead already?

I couldn't find this question asked in such stupid terms. I'm an idiot and need simple questions and answers.

Thanks for your understanding.

Let's assume you're the outside observer. You see 1 BTC go from aaa to bbb, then from bbb to ccc, then from ccc to ddd, and them from ddd to zzz (zzz being associated with service Z). Can you see how easy it is to figure out that addresses aaa, bbb, ccc, and ddd belong to the same person?

It doesn't even get much better if you split the money to different addresses and then reunite it. How often do you think some money flow like

happens without aaa and ddd belonging to the same person?

That's why people use so-called mixing services. A mixing service collects money from several people, as well as addresses to pay the money out to.

As an outside observer, even if you know who the respective owners of addresses 111, aaa, ααα, and 字字字 are, you cannot determine who paid money to zzz, whereas in the first 2 examples, it's pretty obvious what probably happened.

This, of course, is simplified. Similar to how a criminals hiding the origin of their fiat money wouldn't move it to a single bank account in a different country and then back to where they live, mixing services don't give the users their money back after a single iteration. Instead, the money is mixed several times. A graphic showing many iterations and funds of many people, however, wouldn't get the point across very well.

This doesn't help, of course, if an outside observer can match which addresses belong to whom based on how much money went from aaa through the mixer to ΨΨΨ. To prevent such a mapping, the mixer may send money of equal amounts to many addresses. Of course it's a bad idea to reunite the funds afterwards because this makes the owner trackable by amount again.

Note that using a mixing service might be illegal under money laundering laws where you live, especially if it's done with a large amount of money.

Furthermore, a mixing service may just be a scam and the owner will run off with the money given to them.


Security implications of removing CHECKSIG in a test If I conduct an htlc transaction on testnet that does not include OP_CHECKSIG will it still cost an attacker more than (say) $10 in processing power or storage to subvert my tests?

Details: I'm tinkering with BIP-0199 htlcs, the last step of which is CHECKSIG. Now, bitcoind does not (yet) expose htlc functionality through RPC, so in order to tinker I've had to implement BIP-0199 via RPC requests myself. To date I've implemented everything I need up to the final CHECKSIG. I understand of Pieter Wuille here that I would need to implement the signing logic for CHECKSIG myself, which seems logical. However, I'm not interested in the role of CHECKSIG in a htlc as I believe it indistinguishable from the same opcode in any standard transaction so I propose to skip implementing it while my tinkering remains on testnet.

Obviously an htlc without CHECKSIG is not secure. For my purposes is it secure enough: Logically,
1. While it remains on testnet, a successful attack obtains no more than testnet coins;
2. The testnet coins that could be obtained are limited to the funds committed to the p2sh address;
3. An attacker who somehow knew that a redeemscript did not contain CHECKSIG would still have to brute force a script whose sha256 hash matches that of the redeemscript in order to redeem funds;
4. An attacker who sees the seller's redeemscript has to obtain matches for the digest and public key (perhaps through hash tables) and still has to get his copy of the transaction mined first in order to cheat the seller;
5. An attacker seeing the buyer's transaction 'only' has to match on the public key then get his copy mined first to cheat the buyer;
6. An attacker that's too slow to get mined first could nevertheless succeed by getting the block containing the transaction orphaned.

And so, an attack on an testnet hashed time-locked contract that does not include CHECKSIG will still require either processing power and/or storage space well in excess of $10. Is my reasoning sound, and if not, what have I missed?

The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners.  Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions.

There's not much sense in listing and analyzing the vulnerabilities in your method.  Testnet coins are worthless and certainly nobody will take the time to brute-force sha256, or grind through a hash table to get them.

As for checksig-less scripts in general, there are indeed bots on mainnet that listen for such transactions being relayed and try to grab any coins.  It's probably easy enough to run the same bot on testnet.

In any case, if you want to avoid this scenario altogether, you can migrate your setup to regtest.


Send Bitcoin cash to a Bitcoin address by doing a mistake i have send BCH to my BTC address into my own Wallet,the wallet is Bitgo i know they have a tool to recover the BCH when they are send to a non segwit address i have already tried the tool e the tool give error, so i think that my address was a segwit, Bitgo say that when the Address is a segwit address -> Unfortunately, when you sent your transaction, you sent it to a Bitcoin address that was using the new Segregated Witness format. As this format is not supported on Bitcoin Cash, we cannot recover these funds.

It's possible to have another solution

Best regards

Of course it's possible. Since SegWit outputs look like AnyoneCanSpend outputs, you can redeem the outputs.

I can create the redeeming transaction for you, but since transactions with ACS outputs are not relayed, you'll need to find a miner and send your transaction to them, which requires you to e-mail a mining pool owner (No one I've talked to tried this, so I don't know if they will help)

You'll need to check if your SegWit address has spent any Bitcoins. If it hasn't, send the address Bitcoins and spend the Bitcoins from that address.

Maybe you should contact this guy: https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/


Segwit: Arbitrary data storage in witness? Let's say I want to encode the text of the King James version of the Bible into the block chain, one piece at a time (replace this with any zany idea to consume copious quantities of block space). OP_RETURN is impractical because I can only work with 80-byte chunks.

I notice that SegWit allows much more data to be stored - up to 3 MB/block - in witness data.

Clearly, I can't use a V0 witness program because my witness data must take the form

<signature> <pubkey>

However, I believe I can use a V1 witness program. Scripts with that version won't be supported immediately after SegWit deployment, but I notice this in BIP-141:

  If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.

So here's my plan. I'm going to create an output script of the form:

<0x01> <0x0000>

This is a V1 witness program. According to BIP-141, the witness program is not to be interpreted, and the subsequent witness stack will have no size restriction.

Then I'm going to spend that output with a witness transaction input. The witness of my transaction encodes a thousand bytes of text.

When I publish this spending transaction, it will be propagated by nodes. They can't reject it as invalid because that would break forward compatibility when V1 scripts are introduced. BIP-141 says nothing about whether or not such transactions should be relayed (nor does BIP-144), so I assume they will be.

As long as I pay a sufficiently high fee, my transaction should eventually be mined. I even get a 75% discount over using OP_RETURN because my text is encoded in the witness.

And there's nothing the protocol will do to stop me. Or is there?

Edit: to make things simple, assume SegWit has been widely-deployed and that most nodes understand V0 witness programs. Clearly, non-SegWit nodes will not relay a witness transaction because it will be considered non-standard. I'm interested in the behavior of SegWit nodes.

Your transaction, although not invalid, is non-standard. Since it is non-standard, it will not be propagated and will be rejected for being non-standard. However this does not mean that it cannot be included in a block; it can. It only requires that the miner and all of the nodes between you and that miner must be running some software that accepts and relays non-standard transactions. However not many nodes actually do, so you may have a hard time getting good propagation of your transaction.


What causes quadratic hash problem? I read ScriptSig content during signature (quadratic hashing) discussing quadratic hash problem.

Quadratic hash problem is the issue that signing (or verifying) transaction time grows with the square of the number of inputs (O(n^2) where n is the number of inputs).

Why is that so? I reason the following:

For each input you construct different template. O(n)
This template must be double-SHA-hashed. - Double-SHA-hash duration is dependent linearly on the size of the template?
Double hashed template (of fixed length) is then signed. - as the leght is fixed this step is of fixed duration

As step 2 is dependent linearly on the size of the template, thus it is linearly dependent on the number of inputs, giving final time dependency relation O(n^2)?

More precisely O(n^2+m) where m is the number of outputs (as this contributes in step 2)?

Double-SHA-hash duration is dependent linearly on the size of the template?

Yes, of course.

So, increasing the count of inputs twice we also increase the size of each template ~twice and the work for signing/verifying whole transaction increased quadratic


Upgrading Fees in Bitcoin Trading I would like to know what "upgrading" fees are? The guy who's mining my account says I need to pay him $1005.50 more in Bitcoin before they can go on. I only invested $300.00. Does it sound correct?

You are being scammed.

Individual accounts do not need mining, mining is required to secure the network as a whole.

This is a common scam, where they ask you to "invest" a certain amount into mining, and then string you along by asking you to pay more to unlock better returns, or unlock your keys, or whatever other nonsense they can come up with.

Cut your losses and write of the $300, do not send them any more funds.


How to get time of input and output of a given a transaction? I have a transaction ID and I need to get the time of input and the of output of that transaction (Unix timestamp) programatically using a block explorer or any API.

Is this possible ? If so how can I do that ?

Transactions do not have an individual timestamp. The closest you can do is get the timestamp from the block that it was included in (but note Pieter's warning about accuracy).

API Example

Using blockchain.info, for example you can do:

https://blockchain.info/rawtx/$tx_hash

For $tx_hash = b6f6991d03df0e2e04dafffcd6bc418aac66049e2cd74b80f14ac86db1e3f0da this would return:

{
    "hash":"b6f6991d03df0e2e04dafffcd6bc418aac66049e2cd74b80f14ac86db1e3f0da",
    "ver":1,
    "vin_sz":1,
    "vout_sz":2,
    "lock_time":"Unavailable",
    "size":258,
    "relayed_by":"64.179.201.80",
    "block_height: 12200,
    "tx_index":"12563028",
    "inputs":[

            {
                "prev_out":{
                    "hash":"a3e2bcc9a5f776112497a32b05f4b9e5b2405ed9",
                    "value":"100000000",
                    "tx_index":"12554260",
                    "n":"2"
                },
                "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
            }

        ],
    "out":[

                {
                    "value":"98000000",
                    "hash":"29d6a3540acfa0a950bef2bfdc75cd51c24390fd",
                    "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
                },

                {
                    "value":"2000000",
                    "hash":"17b5038a413f5c5ee288caa64cfab35a0c01914e",
                    "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
                }

        ]
}

From there you can query the block height of the inputs the same way as above using the inputs[i].prev_out.hash field. Then, to get the timestamp for a block, just query the raw block by height. E.g. for the output timestamps, you would use block_height: 12200 for the example above:

https://blockchain.info/block-height/12200?format=json

The timestamp would be returned in blocks[0].time

Note: Transactions technically can have an individual timestamp. When they do, it is the locktime property, see Bitcoin Wiki - Transaction. However, the locktime is most likely not going to be the time that it was created, rather, the time it is available for spending:

  if non-zero and sequence numbers are < 0xFFFFFFFF: block height or
  timestamp when transaction is final


A Proof of Concept for P2P Bitcoin Exchange? Has anyone proposed or developed a proof of concept for a P2P bitcoin exchange?

Edit:

Let me add some layers here. How would trust work in a P2P exchange? How would one actually get the money they have exchanged for? Does this require a bank to be involved?

You might want to check NashX project. It's anonymous online Person-to-Person cash exchange that uses Mutually assured destruction to create Nash equilibrium for traders.

http://nashx.com/


Why is 'script' used in a transaction instead of the output address? I see transactions contain script for each output, but this "script" seems to be deterministically derived from the address associated with the output.

Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly?

Scripts can be used to do a lot more thing than just pubkeys and signatures. There is an entire Bitcoin script language that can be used to specify things like multisigs, hashlocks, timelocks, conditionals, etc. It's pretty extensive, just hard to grasp and reason about. Such scripts do not map to addresses (before P2SH) so without having scripts in outputs, you would be locked into using only single pubkeys and signatures.