JSON-RPC call to bitcoind error, 403 failed to open stream I am trying to make a json-call to a VPS server that hosts my wallet and it is failing with the following error message :

Warning:  fopen(http://user:pass@ip:port): failed to open stream: HTTP request           failed! HTTP/1.1 403 Forbidden
in C:\Users\Owner\Desktop\USBWebServer\root\php\jsonRPCClient.php on line 132

Fatal error:  Uncaught exception 'Exception' with message 'Unable to connect to     http://user:pass@ip:port' in     C:\Users\Owner\Desktop\USBWebServer\root\php\jsonRPCClient.php:140
Stack trace:
#0 C:\Users\Owner\Desktop\USBWebServer\root\php\testrpc.php(15): jsonRPCClient- >__call('getinfo', Array)
#1 C:\Users\Owner\Desktop\USBWebServer\root\php\testrpc.php(15): jsonRPCClient-   >getinfo()
#2 C:\Users\Owner\Desktop\USBWebServer\root\index.php(154): include('C:\Users\Owner\...')
#3 {main}
thrown in C:\Users\Owner\Desktop\USBWebServer\root\php\jsonRPCClient.php on line 140

i got my JsonRPCClinet.php file from here http://jsonrpcphp.org/code.php?file=jsonRPCClient

my bitcoin.conf file is as follows:

server=1
daemon=1
listen=1
rpcuser=user
rpcpassword=pass
rpctimeout=16
rpcallowip=0.0.0.0
rpcport=8332

i am aware that 0.0.0.0 is dangerous , i will change it once i can get things working

i am calling json-rpc using this php code

<?php
  require_once 'jsonRPCClient.php';

  /* Configuration variables for the JSON-RPC server */
    $rpc_host = 'ip';
    $rpc_port = '8332';
    $rpc_user = 'user';
    $rpc_pass = 'pass';

    $btc = new jsonRPCClient('http://' . $rpc_user . ':' . $rpc_pass . '@' . $rpc_host . ':' . $rpc_port);

  echo "<pre>\n";
  print_r($btc->getinfo()); echo "\n";
  echo "Received: ".$btc->getreceivedbylabel("BEkpbpYLpwacchSQFRCL7ZSWw3VwB8k7WN")."\n";
  echo "</pre>";
?>

additionally i have opened port 8332 on my VPS

can anyone see any reason why this error is occurring, i would greatly appreciate the help

I just read through the code that handles rpcallowip, and I can tell you that rpcallowip=0.0.0.0 won't work.

If you want to allow from all addresses, you should use

rpcallowip=0.0.0.0/0

(Weirdly, I can't find any code that handles wildcards. I'm going to open an issue on github about it. It looks like either the documentation or the code is wrong.)

Edit: It turns out that wildcard support has been removed.


Where does one find documentation for the MtGox trade API? I find a lot of references to it, ruby-wrappers etc., but where can one find actual documentation for the MtGox API?

Here is their documentation for their http based api and here is their documentation for the websockets based one.

There are many wrappers in many languages already written.

Ruby
Node.js
Python

just to name a few


Why do some Bitcoin Core "good first issues" require scripted-diffs? I am looking at a good first issue on the Bitcoin Core repo to find and replace a string. But it appears I need to write a scripted-diff and the examples look complicated. What is the point of the scripted diff? Why is it required for such a simple change?
This question was asked by prayank23 on GitHub and has been paraphrased.

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

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


How do I find the nodeid of the node issuing a lightning network invoice? I recently got an BOLT11 invoice from a store. For example this one:

LNBC13934430N1PWJUJEZPP5K7FLC2M5CLHTWMTF3HZDN7VVRCA4RNFAFA89F2D6KGYWW4JCSDAQDZ62PSKJEPQW3HJQ4RGV5SYC6T8DP6XU6TWVUSYXMMWVEJHYETWVDJJQ2Z0WFJX2U3QF9ZR5GZ5F3PNZWFD25UY54Z39YXQZURCQP2RZJQG8ZM9WXGVHZPMUQEWY9J9KDQNRVLZHPCWM6S8CVLC2CKRDNELE42Z9U5VQQY3SQQYQQQQL8QQQQPJQQ9Q6KM84F7KTW6UV574UR2LFNKZLM7VNK8NJRZV20JD8SAW6FZ3TQGSZE6YUT0X2UXGDGYJZGTXEFSQSSEVTKFF97P3TER5K23ZPHDDXHQQ95UT4N

Luckily I my node was able to find a route to the destination but if it wouldn't? How could I find out the nodeid to open and fund a direct payment channel with the store? They did not say anything about their nodeid on their website.

Lightning invoices are signed by the node issuing the invoice in order to verify the signature we need to know the node id. Thus it is included in the invoice. Lightning nodes provide an API to decode invoices.

In c-lightning you can do (lnd below!)

lightning-cli decodepay LNBC13934430N1PWJUJEZPP5K7FLC2M5CLHTWMTF3HZDN7VVRCA4RNFAFA89F2D6KGYWW4JCSDAQDZ62PSKJEPQW3HJQ4RGV5SYC6T8DP6XU6TWVUSYXMMWVEJHYETWVDJJQ2Z0WFJX2U3QF9ZR5GZ5F3PNZWFD25UY54Z39YXQZURCQP2RZJQG8ZM9WXGVHZPMUQEWY9J9KDQNRVLZHPCWM6S8CVLC2CKRDNELE42Z9U5VQQY3SQQYQQQQL8QQQQPJQQ9Q6KM84F7KTW6UV574UR2LFNKZLM7VNK8NJRZV20JD8SAW6FZ3TQGSZE6YUT0X2UXGDGYJZGTXEFSQSSEVTKFF97P3TER5K23ZPHDDXHQQ95UT4N
{
  "currency": "bc",
  "created_at": 1563314978,
  "expiry": 899,
  "payee": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365",
  "msatoshi": 1393443000,
  "amount_msat": "1393443000msat",
  "description": "Paid to The Lightning Conference (Order ID: TLC19-U8JTQ)",
  "min_final_cltv_expiry": 10,
  "routes": [
    [
      {
        "pubkey": "020e2d95c6432e20ef80cb885916cd04c6cf8ae1c3b7a81f0cfe158b0db3cff355",
        "short_channel_id": "572579x582x1",
        "fee_base_msat": 999,
        "fee_proportional_millionths": 200,
        "cltv_expiry_delta": 40
      }
    ]
  ],
  "payment_hash": "b793fc2b74c7eeb76d698dc4d9f98c1e3b51cd3d4f4e54a9bab208e75658837a",
  "signature": "3045022100d5b67aa7d65bb5c653d5e0d5f4cec2fefcc9d8f390c4c53e4d3c3aed245158110220016744e2de6570c86a09212166ca6008432c5d9292f8315e474b2a220ddad35c"
}

In particular we find the entry which reveals the node of the store:

 "payee": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365"

We can query the gossip store for more information about the node with the following command:

lightning-cli listnodes | grep 024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365 -B 1 -C 13
    {
      "nodeid": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365",
      "alias": "www.fulmo.org",
      "color": "f2f3f4",
      "last_timestamp": 1561973177,
      "globalfeatures": "",
      "global_features": "",
      "addresses": [
        {
          "type": "ipv4",
          "address": "95.211.207.81",
          "port": 9735
        }
      ]
    },

This gives us all the information we need to peer with the shop and fund a channel.  (In case the node was private we could use the routes hints from the decoded invoice to connect to a public exit node.)

lnd users

If you are using lnd you can use the command DecodePayReq and instead of invoking listnodes to get the information from the gossip store you can invoke GetNetworkInfo


"Market capitalization" over time Is there a convenient data source and/or graph that gives the "market capitalization" over time for Bitcoin (i.e. the number of bitcoins issued to date times their current value on the big exchanges).

Note e.g. some publicity and attention to this issue due to the xkcd infographic on Money:

Money - XKCD
Zoom in to the part about bitcoin or see the original version:

Note that the date indicated there for the peak so far (July 2011) is wrong, since that peak was on June 8 or 9.  It would be fun to provide some more accurate and precise numbers, though of course there is no one canonical exchange rate and some sort of weighted price may be more useful than the very highest trade recorded.  See some nearby data at:
 bitcoin charts 2011-06-08..11

Update: A closer look at the minute-by-minute data suggests that the peak was at     2011-06-08T17:10  when the mtgox USD price was $31.91.  At that point the most recent block was  http://blockexplorer.com/b/129412 at 2011-06-08 16:56:29 (assuming both services are using the same timezone? UTC?).  That implies $206,476,846 I think: 31.91 $/BTC * 129412 blocks * 50 BTC/block

See also the nice new Bitcoin Pie site that compares market cap for various bitcoin-related currencies (and see Is there an easy way to check out the market cap of the alternative currencies? - Bitcoin - Stack Exchange).

http://blockchain.info/charts/market-cap. 24 hour Weighted price from mt.gox and tradehill.


Is it possible to shift/modify a ECDSA keypair by a scalar where the public key can be computed using only public information? I am looking for a method which would allow a keypair to be modified in a manner which is unpredictable to the original creator.

So I was thinking a user creates a key and commits it by making a transaction which is written to the blockchain.  The block hash could be used as a source of unpredictability to derive a new keypair.  Can this be done in a manner than only the derived private key can be computed from the original private key and the derived public key can be computed without the original or new private key?

Let:

k = existing private key
K = existing public key
B = hash of block hash
k' = derived private key
K' = derived public key

Is there some pair of functions such that solves the following?

K' = FPub(K, B)
k' = FPriv(k, B)

Are there any security implications?

To be clear the new public key should be derived using only public information (existing public key and scalar).

I believe simple Elliptic Curve addition should accomplish what you are looking for. The process is similar to how child private and public keys are derived from parent keys in BIP32 (HD) wallets.

def FPub(K, B):
    block_pub = hash(B)*G
    // Note that the below addition represents ECC addition
    return block_pub + K

def FPriv(k, B):
    block_priv = hash(B)
    // Note that the below addition is addition mod curve order 'n'
    return block_priv + k

Note that hash(B) is used instead of B itself because B is not sufficiently random (it starts with a string of 0 bits).

With this scheme, any observer can very the chain of public keys, but only the owner of the original private key can derive the private key for any step in the chain.


Why does my c-lightning node pay more than the invoice plus routing fees? A friend sent me an invoice for 500,000 Satoshis. To my surprise, I sent 502294 Satoshis.

Here's what I see from my c-lightning console:

"msatoshi": 500,000,000
"msatoshi_sent": 502,294,595

My friend received a different amount on lnd:

"value": "500000"
"amt_paid_sat": "501791"

Any reasons why I am not sending the amount requested on the invoice? Also is my understanding correct that I paid 503 satoshis in fees for this transaction? It's more than I expected on the lightning network.

Thanks,

Francois

In your c-lightning node you have configured your maximum fee rate which is used by the pay command to do the payment.

The BOLT04 describes how overpaying up to twice the amount to obfuscate payments in order to have better privacy is part of the protocol:

  if the amount paid is more than twice the amount expected:
  SHOULD fail the HTLC.

  SHOULD return an incorrect_or_unknown_payment_details error.

  Note: this allows the origin node to reduce information leakage by altering the amount while not allowing for accidental gross overpayment.

In combination with this merged pull request c-lightning fixed this issue
implementing random overpayments up to the maximum fee rate.

So generally c-lightning will randomly overpay your transaction with an amount that is lower to the maximum feerate you are willing to pay.

Not that in earlier days lnd did not accept overpayments as they seemed to not have implemented this part of the protocol.


Transaction with duplicate address in the output I came across this transaction and noticed that there's duplicate address for the output part.
https://live.blockcypher.com/ltc/tx/ada86c7d6f46f712bfa04982f17ce9cd9d4c2560e3493de9c22f8b135ece6cb9/

When I tested the rpc command "createrawtransaction" to create a transaction that would send to duplicate address in the output, it gave me the error

error code: -8
error message:
Invalid parameter, duplicated address:

Which command to use if I want to send to duplicate address in the output?

There is no command that allows you to do that. While there is no network relay or consensus rule that prevents this, the wallet side has its own rules and will prevent you from doing this as it is largely pointless. If you really want to send to the same address multiple times, you will need to create the transaction bytes manually without the use of any of the RPC commands.


Best strategy for using hundreds of 1 kh/s CPU litecoin miners Some friends and I currently run a webapp and we rent 50 dedicated servers that run a few dozen linux VMs each. During the night they are not used a lot so we thought we could use them for cpu mining litecoin. We know that thats normally not profitable but we rent the servers for a fixed price so we could at least make a little money back each month.

Each VM gets roughly 0.5 to 2 kh/s. We already tried some LTC mining pools however all the ones we have found had pretty high share difficulties (64 and higher), so we only rarely got confirmed shares because clean_jobs=True messages would come before a VM could finish a share.

We are now also considering setting up our own internal mining pool that connects to a bigger external pool and divides shares further for our VMs.
We also considered using some other altcoin type thats more suitable for CPU mining, but that mostly seems more trouble than it's worth.

Whats the best way to utilize such a setup?

Thanks guys!

Most likely it isn't worth the effort, even if you're not paying for electricity. But if you want to do it, CPU coins are the way to go. I'm not sure why you consider it "more trouble than it's worth." Check out the profitability calculators for Memorycoin and Primecoin to see if they're worth your time. If you don't want to hold those coins, you can sell them on an exchange for Bitcoin or Litecoin.


How can I tell when `rescanblockchain` is finished? Rescanning the blockchain can take some time. How can I tell (via RPC) when the rescanblockchain command has finished? Will it block until it's done, and only then return? Or is there another RPC I can use to see its progress?

Does the same answer apply to other RPC calls that might trigger a rescan, such as importmulti and loadwallet?

I'm worried about (if it blocks) the user experience of sitting there for possibly minutes with no progress indication; or (if it doesn't block) future RPC calls (such as getbalance) getting stale info before the rescan has completed.

rescanblockchain will block until it is complete. This will happen for any RPC which rescans the blockchain.

However, this does not mean that the RPC interface is unusable. You can still interact with it from another thread. If a rescan is taking too long, you can use abortrescan from another thread/process (e.g. another terminal session) to cancel the ongoing rescan.

There are no RPCs for seeing the progress of a rescan. However, if you are using bitcoin-qt, a dialog window will appear with a progress bar showing the rescan progress.


How does lightning network find paths with sufficient liquidity? According to this article article, all hops along the route must have sufficient liquidity to process any payment they wish to service.

However, in LN, new commitments may not to be broadcast to the blockchain until one wants to close a payment channel. How does LN know that a node has sufficient liquidity when a node has paid out all its bitcoins but the transactions have not been broadcast yet?

Lightning Network nodes have their own P2P network where they send messages to each other containing information about their channels and their states. So a node will receive messages from the other nodes on the network that describe the available channels and their liquidity. So a node can build an internal map of the network's channels and the balances for each node in each channel. With this map, it can then plot a route for each payment.


Are there any studies into the size of the blockchain scaling over time? After watching some of one of the 28c3 talks, It got me thinking about just how scalable Bitcoin really is.

With the size of the blockchain currently, given the number of transactions/users, will the size of the blockchain be manageable as Bitcoin adoption increases?

As an example (no answers about "this will never happen" please), if Bitcoin was as large as a company like VISA, hundreds/thousands of megabytes would have to be transmitted over the network daily and stored in the blockchain. This is not including other things being stored in the blockchain that essentially shouldn't be (Eligius putting prayers in the blockchain for example).

This would mean that most casual users would need to use a thin client as storing the blockchain and keeping it up to date would require super fast internet and masses of hard drive space. (imagine Visa's 92 billion transactions per year)

Are there any studies into the scalability of the blockchain? Or is the assumption that technology will be so advanced by the time of this ever occurring that it will not be an issue? (which doesn't sound like the greatest conclusion in my opinion)

Also, quoting the wiki:

  At very high transaction rates each block can be over a gigabyte in size. These blocks must be stored somewhere. Whilst for speed it'd be ideal to store the block chain entirely in RAM, for cheapness storing only the hot parts in RAM and the rest on disk is the way to go. A 3 terabyte hard disk costs less than $200 today and will be cheaper still in future, so you'd need one such disk for every 21 days of operation (at 1gb per block).

3 TB every 21 days? 52 TB a year for the blockchain alone? Is that REALLY scalable?

Satoshi Nakamoto addressed this issue in the original crypto forum thread.

  Long before the network gets anywhere near as large as that, it would be safe
  for users to use Simplified Payment Verification (section 8) to check for
  double spending, which only requires having the chain of block headers, or
  about 12KB per day.  Only people trying to create new coins would need to run
  network nodes.  At first, most users would run network nodes, but as the
  network grows beyond a certain point, it would be left more and more to
  specialists with server farms of specialized hardware.  A server farm would
  only need to have one node on the network and the rest of the LAN connects with
  that one node.

  The bandwidth might not be as prohibitive as you think.  A typical transaction
  would be about 400 bytes (ECC is nicely compact).  Each transaction has to be
  broadcast twice, so lets say 1KB per transaction.  Visa processed 37 billion
  transactions in FY2008, or an average of 100 million transactions per day.
  That many transactions would take 100GB of bandwidth, or the size of 12 DVD or
  2 HD quality movies, or about $18 worth of bandwidth at current prices.

  If the network were to get that big, it would take several years, and by then,
  sending 2 HD movies over the Internet would probably not seem like a big deal.


Can I download the whole block chain from somewhere? Every time I turn on the Bitcoin client it takes days to catch up with the block chain.

Are there alternatives to getting it trickling through the peer-to-peer network? Can I just download it somewhere? Wouldn't this be ideal for distribution via BitTorrent?

If so, how do I import it into the Bitcoin client?

My client would still be validating this data (can it?), and it is all signed and proof-of-worked, so there is no real security problem here, is there?

Note by Murch: This download link is broken and it seems unlikely to me that anyone still provides this service. Network and synchronization code have been immensely improved over the years so that the initial block download via the network is usually acceptably fast.

You can download the blockchain nightlies handled by tcatm (one of the Bitcoin core developers and the operator of bitcoincharts.com). Unpack and copy&replace blkindex.dat, blk0001.dat files into C:\Users\"username"\AppData\Roaming\Bitcoin for Windows 7, and run bitcoind with the -rescan option. Then it will take only a couple minutes to download up to latest block. Be aware that manually copied blocks won't get verified.


Derive public key from xpub? I woud like to obtain an extended public key of a derivation path (m/84'/0'/0').
I'm using btclib, and I have the xpub of the root account.
When I try to use bip32.derive("xpub...","m/84'/0'/0'")
I get btclib.exceptions.BTClibValueError: invalid hardened derivation from public key
What am I doing wrong ?

Review BIP32:

The fact that they are equivalent is what makes non-hardened keys
useful (one can derive child public keys of a given parent key without
knowing any private key), and also what distinguishes them from
hardened keys. The reason for not always using non-hardened keys
(which are more useful) is security; see further for more information.

That little apostrophe ' means that branch of the key derivation tree is "hardened" -- and THAT means that you must have the private key to derive its child keys.
So if you have the PRIVATE key for m/84'/0'/0' you can generate child keys for example m/84'/0'/0'/0 or m/84'/0'/0'/0' (these are two different keys, one is hardened the other is not).
If you were to derive the non-hardened key at m/84'/0'/0'/0 then you could use an xpub FROM THIS KEY (not any of the parent keys) to derive public child keys, without any private keys. Examples would be m/84'/0'/0'/0/0 and m/84'/0'/0'/0/1


Antminers - Can you monitor via SNMP, and set up configuration file Chron Jobs I have an antminer and its very loud. Is it possible to set up a chron job to stop mining, apply a new config file with a lower clockrate and set fan speed overnight? Then to do the same at 7am but overclock it to compensate for the lower hashrate overnight.

Are they also compatible via SNMP? Would like to monitor the temps and if the system is rebooting itself.

The Antminer software doesn’t support anything for automation like this, though you can ssh in and make these modifications manually. There is no support for remote monitoring with SNMP, but there is an exposed cgminer API for remote configuration.


Is it possible to connect remotely to a c-lightning node with an exposed TCP port? If you run a c-lightning node with EXPOSE_TCP set to True, it seems to me it should be possible to connect with it remotely, provided that the c-lightning RCP is listening to all incoming traffic. (IP is set to 0.0.0.0)

I tried the Docker setup recommended in the c-lightning readme and when I use socat to connect directly from inside the Docker container everything works smooth:

socat - UNIX-CONNECT:/home/simnet/.lightning/lightning-rpc

But when I try to use socat from the container host the connection closes directly upon opening with no error or anything:

socat -  tcp:127.0.0.1:14302

The ports seem to be mapped correctly

0.0.0.0:14302->9835/tcp

I don't understand what I am missing here. Is it even possible to connect remotely with this setup? I've read this question as well, and the answer suggests to use socat inside the Docker container to bridge the Unix socket to TCP, but it seems to me that the EXPOSE_TCP is meant to do exactly that natively.

UPDATE: The API doesn't really seem to be exposed over TCP after all, although the parameter is certainly set to True.
This is how I found out:

I wasn't even able to use the API over TCP from inside the docker container
Then I bridged the Unix socket to TCP manually by using socat. socat -d -d TCP-LISTEN:9835,fork,reuseaddr UNIX-CONNECT:/home/user/.lightning/lightning-rpc
After this I was able to connect to the lignting-c node remotely.

So maybe there's something wrong with c-lightning in interpreting this setting, or maybe there's something wrong with my setup. I'll explore further and report back.

EXPOSE_TCP is implemented in c-lightning's docker script:

https://github.com/ElementsProject/lightning/blob/2945b25b57db37dca31c10da34a4b1ca33d697c3/Dockerfile#L103

https://github.com/ElementsProject/lightning/blob/master/tools/docker-entrypoint.sh

If you didn't use that script or didn't implement it in your own docker script, it won't work.

It's easy to mistake EXPOSE_TCP for a parameter you can set when spinning up c-lighting.


MtGox - trusted vs verified What is the difference between a "trusted", "verified" and other accounts at MtGox? In order to get "verified", one needs to provide them with photo ID and utility bill, but how does one get "trusted"?

At the time of this writing, "Verified" Accounts are eligible for monthly/daily withdrawal limits up to 10 times the default daily amount and 5 times the default monthly amount, while "Trusted" Accounts are eligible for monthly/daily withdrawal limits up to 100 times the default daily amount and 50 times the default monthly amount.

For verified status it is enough to send by email a scan of the ID and bill, and they only need to be translated if they don't include an English name. For trusted status, physical copies of the documents must be sent by mail, they must be certified by an apostille, and if they are not completely in English they must have a notarized translation.

The withdrawal limits for normal / verified / trusted accounts are:

Daily BTC: 400 / 4,000 / 40,000
Monthly BTC: No limit
Daily USD: 1,000 / 10,000 / 100,000
Monthly USD: 10,000 / 50,000 / 500,000

You can also choose to lower your limit if you want.


Testnet Bitcoin wallet: which script in hash addresses? Why does the Testnet Wallet create receiving addresses in the form of script hash addresses (prefix 2) instead of "plain" m/n-prefixed addresses? Is there any security reason? And, which script does it hash? I was assuming, from BIP.16, a single-signature case:

scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ]
OP_EQUAL

But I was not able to obtain the same script hash (of course I know the private key). I tried the following steps:

$ echo [02b6d...public key...47f89] checksig > script
$ bx script-encode < script | bx sha256 | bx ripemd160
046f...fb3
$ echo hash160 [046f...fb3] equal > script2
$ bx script-encode < script2 | bx sha256 | bx ripemd160 | bx base58check-encode --version 196
2NxxxexxxxxL

(I had expected to get the same result built by the wallet, but they were different).
Please note that I know for sure both the private and public keys.

What're seeing is a P2SH embedded Segwit address.

It contains the hash of the script OP_0 [20-byte hash160 of compressed pubkey].

You can configure Bitcoin Core to instead produce legacy P2PKH addresses (start with -addresstype=legacy). You can also make it construct Bech32 (BIP173) addresses using -addresstype=bech32, which represent the OP_0 [20-byte hash160 of compressed pubkey] script directly. These are cheaper to spend, but not all software supports sending to them.


Is there a bitcoin exchange accepting SEPA transfers? Since mt.gox had to close its european office, is there any other exchange accepting SEPA transfers?

Sending a wire to the HK office costs much more than a SEPA transfer to me, and I'd like to avoid that extra expense if possible.

EDIT This information is now out of date - voting to close this question

You could use Intersango

It's a well-trusted exchange that operates within the Eurozone (and in the UK). You see their current fee structure provides SEPA transfer:

Country             Accepting deposits  Processing withdrawals
GBP (domestic)      Free                Free
EUR (SEPA)          5 PLN (1.23 EUR)    5 PLN (1.23 EUR)
EUR (international) 10 PLN (2.46 EUR)   0.2%, capped: 9.5 PLN min, 180 PLN max
<snip>


Why does Ripple needs to have a long ledger? Why does ripple need to maintain a long ledger? Why is it not enough to maintain only the most previous transaction details? What is the purpose of having a long history ledger?

First note that Ripple uses the term ledger slightly differently than general use.

In Ripple a ledger is the set of all Ripple accounts, all their current balances, all open trade offers, and only the transaction details that justify the changes in this ledger from the previous ledger. A specific Ripple ledger does not contain any other past history of transactions.

Even so, a Ripple ledger can still be somewhat large due to implementation details of it's binary representation. The implementation values lookup speed, syncing efficiency, hashing of sub-parts, and other features over absolute size.

Transaction history in Ripple is stored by servers keeping multiple past ledgers, as many as desired, that form a chain similar to Bitcoin's block chain. However, unlike Bitcoin, it's possible for new transactions to be processed by a Ripple server that only has the last validated ledger. Such servers (validators) are free to discard all older ledgers (and their transactions).

Currently most public facing Ripple servers (that accept transaction submissions and state queries) maintain a near fully history of all past ledgers and can therefore answer queries relating to historical information (e.g. a list of past transactions that effected a specific account via the account_tx API), but there is no requirement for any given Ripple server to make such history available (servers inform clients of the range or ledgers they have available).

It's desirable to have at least a few Ripple servers making as much past history as possible publicly available so that anyone interested can query information about past transactions. For example, it is expected that gateways will run Ripple servers for their customers and would configure at least some of those to store the full history since the gateway's inception (at least).

As the storage requirements for full history increase it may become more common to have "slim" Ripple servers that only store a fixed history (perhaps a few weeks worth) for cost reasons. Ripple clients could use these for faster day-to-day operation (for example if their were more of these or if they were located closer to the client) and only need to query the potentially slower (for example if they're fewer and more overloaded or farther away from the client) servers when more ancient history is required.


When does OpenCoin Inc intend to make the Ripple server code public? Is there a definite timeline or not? Thank you.

We have publicly stated that we don't expect the code to be made publicly available in less than two months and that we would consider it a failure if we didn't make the code publicly available before the end of the year.

Right now, we've received a lot of public feedback and are trying to make changes responsive to that feedback. See this github issue for an example. It will be very hard to make significant changes after the source code is public.

(I'm an employee of Opencoin and one of the designers of the Ripple payment network. I'm speaking only for myself.)


Calculating average number of hashes tried before hitting a valid block I'm toying with the idea of starting to mine, and was wondering how to calculate how many hashes on average must be tried before one will "hit" a valid block?  I'm talking about a single user (not a pool) using one rig.

Well, currently the difficulty is 2,440,643.  There will be (difficulty * 2^32) (roughly) hashes per block.

So that means there are (2,440,643 * 2^32) hashes that must occur before one block is solved.  That's is across the entire network.

A block is solved in ten minutes (on average) or 600 seconds.
So the network is hashing (2,440,643 * 2^32) / 600  ~= 17 Thash/s.  (This calculation is performed and the result is displayed on BitcoinWatch.com)

Let's say your dual 5970 rig gets 1.4 Ghash/s.  That is 17,770 Ghash/s / 1.4 Ghash/s = 12,693.  That is the number of rigs, if all were exactly like yours, operating today.

So if 12,693 rigs can do the work in 10 minutes, one solo rig will tka 12,693 * 10 minutes, or 126,930 minutes.    With 1,440 minutes in a day, that means it will be about 88 days before you will have a 50% chance of solving a block operating solo.

Now that was the long way.

The short way:

http://tpbitcalc.appspot.com/

For Hash Rate, plunk in 1400 (1.4 Ghash/s) and click Calculate.

So then, how many hashes is that?  There are 86,400 seconds in a day and you have to has for 88 days.  86,400 * 88 = 7,603,200 seconds.  At 1.4 Ghash/s X 7,603,200 seconds means you hashed 10,644 Thashes.

That is: 10,644,000,000,000,000 hashes.


blockchain.info transaction timestamps set into the future There seem to be some irregularities with Blockchain.info's transaction timestamp (aka Received Time) for a set of blocks.  The transaction times are recorded with unix timestamps well into the future (2017, 2022, 2035, etc..)

For example, here is a transaction in block 237173 with a timestamp of 2035-05-27 00:00:59.

All the blocks that have transactions with a future Received Time are as follows:

237173
237175
237180
237181
237182
237183
237184
237185
237186
237187
237188
237189
237190
237191
237192
237193
237194
237195
237196
237200
237201
237202
237210
237280
237945
237980
238008
238013
238038
238227
239127
240078
241223
260657
260819

1) Are these valid transactions?

2) If they are valid, how can I assign a valid timestamp to these transactions?  Would it be 'fair' to simply assign them the block's timestamp?

3) From what I understand about the Received Time, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring?  Is it a bug?

1) Are these valid transactions?

Yes

  2) If they are valid, how can I assign a valid timestamp to these
  transactions? Would it be 'fair' to simply assign them the block's
  timestamp?

You can do anything. Yesterday I've timestamped them as 1905, today as 2048

  3) From what I understand about the Received Time, it represents the
  time that bc.info sees the transaction, so how can this this timestamp
  be occurring? Is it a bug?

Yes.


Generate Bitcoin Address JS Step-By-Step "Invalid Address" Error I am following the process for bitcoin address creation as outlined in Mastering Bitcoin, however, when I try to reference this address in my bitcoin-cli, which is set to regtest, it responds with an invalid address error. I am attempting to write some JS to interact with my bitcoin node via the bitcoin-core package, but instead of just using all the built in commands, write some of the code myself to solidify my understanding.

I am using the following npm packages:

const EC = require('elliptic').ec;
const ec = new EC('secp256k1');
const bs58 = require('bs58')
const SHA256 = require("crypto-js/sha256");
const RIPEMD160 = require("crypto-js/ripemd160");

Here is my address creation function.

function createNewAddress() {
  // Get the private key
  const privateKey = ec.genKeyPair()
  // Get the public point from the private key
  const publicPoint = privateKey.getPublic();
  // Uncompressed public key
  const uncompressedPK = publicPoint.encode('hex');
  // SHA256 then RIPEMD160, aka HASH160
  const hashedPK = RIPEMD160(SHA256(uncompressedPK).toString()).toString();
  // Prepend the version, here we use 6F got the testnet (we are using regtest)
  const prependedPK = "6F"+hashedPK;
  // Calculate the checksum and take the first 4 btyes
  const checksum = SHA256(SHA256(prependedPK).toString()).toString().substring(0,9);
  // Append the checksum to the end
  const unencodedPK = prependedPK + checksum;
  // Base58Encode the unencodedPK
  const bytes = Buffer.from(unencodedPK, 'hex');
  const bitcoinAddress = bs58.encode(bytes);
  return (bitcoinAddress);
}

Here is a simple output:
mtURXDaisk6ustpeo7LuiZYje9yV31JhBN

You are hashing everything as hex strings. However that is not the proper way to hash stuff. They should all be hashed as bytes (i.e. the raw data), not strings of hexadecimal.


Transaction fee is based on only "transaction size" ? or depends on "transaction amount" as well? In the Bitcoin, transactions fees are different in value. Now the question is that this transaction fee is based on only "transaction size" ? or depends on "transaction amount" as well ?
For example, consider transactions A and B have same size. However, amount of transaction A is 2 bitcoins and amount of transaction B is 1 bitcoin. In this case, these two transactions have equal fee ?

First, when we quote a "Bitcoin transaction fee", we will usually quote one of two numbers:

Consumers care about the total fee.This is the total fee that you're paying in a transaction, such as 10,000 satoshis or 0.0001 bitcoins. This is probably the most important number for consumers as they only care about the fees associated with their particular transaction.Miners care about the fee per byte (or kilobyte).This is the total fee divided by the number of bytes in a transaction, such as 40 satoshis/byte or 0.0004 bitcoins/kilobyte. This is the most important measurement for miners. The reason is that they use this to decide whether to include your transaction in the blocks they attempt to produce, as they can only include about 1 million bytes of transactions in their blocks. As such, they prefer to include transactions that pay more fee per byte.

It's important to note that the total bitcoin amount of your transaction doesn't matter for the purposes of fee calculation! For example, if your transaction is 250 bytes, you'll have to pay the same fee whether you're transferring 0.001 bitcoins or 1 million bitcoins.

For a transaction that you've already sent, you'll find either one of the numbers above or both numbers above on a block explorer.  For transactions you haven't sent yet, you probably want to find the best fee-per-byte to ensure your transaction confirms quickly.


Optimizing fee payment for speed or zero fees/privacy? (Clients vs. e-wallets) As far as I understand the more fees you pay, the faster the delivery. What I don't understand is fees are given to kilobytes of data, not amount of money.

Maybe here would come handy a little deeper basic understanding how bitcoin works behind the scenes, maybe I should read this book?

I don't know, but the bigger the money the bigger the block size? Or the newer the money the bigger the block size? Or a little bit of both? As the miner solve more and more complex calculation problems(?). And the older the bitcoin block, the cheaper the transfer, regardless how big the amount is?

Consider 2 cases:

1st, you want to optimize for lowest or zero fees: time is not an issue. In this case as I understand bitcoins are transferred in chunks to save on fees. Does it also increase you privacy as well? How much time it takes to transfer a quadrillion dollars (or a little less), and what is the absolute minimum fee for such a large transfer?

2nd, you need instant delivery. I'm not sure about the fee structure (does it depend on the client or wallet you use?) but is it a fixed or variable % or a fixed amount per transaction? In the Qt client you can set an amount for fees but how do you calculate to spend the absolute minimum fees for an instant delivery? That would be just optimal, right?

As e-wallets use a share address, transferring funds in between bitcoin addresses of the same e-wallet should be free, and instantaneous, right? Instawallet?

Do I have the choice if I want to optimize for speed or costs (and maybe privacy?) with the various e-wallet providers? Let's say I want to spend instantaneously from an e-Wallet BTC 1 but I want to know beforehand how much I should transfer to that wallet in advance (slow transfer, zero fees) to include the appropriate (fast) fees.

The amount of bitcoins transferred is not the scarce resource you are paying for, disk space is. The distributed ledger that keeps track of the balance of each address is replicated on all participating nodes. That means that each KB more in your transaction is replicated thousands of times.

For the speed: all transactions are treated equal (except if they are deemed invalid as they in the case of a double-spend) so they are distributed over the network with the same speed. The fee comes into play once many transactions are available to be included in a block, i.e., they are still unconfirmed. As blocks have a maximum size (currently 1MB) there is a limited number of transactions that will be confirmed by a block. Miners will try to optimize their revenue from transaction fees of transactions that are included in the block, filling up with transactions that do not include fees.

Adding a fee to your transaction will increase the probability of it being included in a block, i.e., being confirmed.

The transaction size is dependent mainly on the number of inputs that are claimed. As the number bitcoins from an output have no influence on its size the number of bitcoins transferred in a transaction does not influence the transaction size.

As for e-Wallet internal transactions: they are likely not handled by the Bitcoin network but internally, thus completely independent from the network rules.


java.lang.NoClassDefFoundError: org/spongycastle/util/encoders/Hex in Java when dealing with Bitcoin addresses I have a private key bigInt of type bigInteger and I would like to generate the address corresponding to this private key. I implemented the following function

public String get_address () {
Address address = new Address(NetworkParameters.prodNet(), Utils.sha256hash160(new ECKey(bigInt).getPubKey()));
return address.toString();
}

When compiling, I have

Exception in thread "main" java.lang.NoClassDefFoundError: org/spongycastle/util/encoders/Hex
at com.google.bitcoin.core.NetworkParameters.<clinit>(NetworkParameters.java:49)
at bitcoin.get_address(bitcoin.java:40)
at main.main(main.java:11)
Caused by: java.lang.ClassNotFoundException: org.spongycastle.util.encoders.Hex
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 3 more

I guess that I need to import the library org.spongycastle but I don't know how to do that in Eclipse.

Who can help me with this?

Thanks a lot.

You need to resolve the dependency org.spongycastle.util.encoders.Hex, more than likely you need to add this dependency to your pom.xml file if you are using Maven. If you are not using maven, you will have download the JAR file from somewhere and I add it to your build path in Eclipse.

From a quick Google search this appears this is  the dependency that you want.


Why does the block explorer show a different fee rate than what I selected in my wallet app? I know this could have something to do with the fact that I was sending from a lightning wallet, but I would like to know why the transaction on blockchain.com shows my fee as being ~6.5 sats per byte when I selected 10 sats/byte as I sent the transaction.

Feerates on the Bitcoin network are expressed in sats/vbyte (where vbyte is bytes, but taking the segregated witness discount into account). blockchain.com shows sats/byte (where byte refers to the actual number of bytes used to serialize the transaction); this metric is meaningless for fee estimation purposes.
blockchain.com doesn't show sats/vbyte directly, but you can compute it from the sats/WU that they do show (1 vbyte = 4 WU, so N sats/WU means 4N sats/vbyte).
I recommend using a different block explorer (or none at all; your own wallet will tend to give you more correct interpretations, without needing to trust a single site).
See also: https://murchandamus.medium.com/psa-wrong-fee-rates-on-block-explorers-48390cbfcc74


Can I sign and redeem many outputs at the same time? (shrink the size of a tx Input) I'm looking at this transaction that is redeeming many historical outputs from the same address.

When I look at the blockchain, it seems pretty clear there is redundancy here of the public key being repeated over and over again.  If I could consolidate that, I could save on transaction fees, and bloat in the blockchain by signing all of them at once.

Is there a way to have one signature redeem many inputs at once?  Perhaps using P2SH?

Unfortunately by design, each scriptSig is verified slightly differently, so a different sig is required to redeem each input.


Wallet transfer status stuck So, I'm just starting out with bitcoin. I bought a little bit and moved it to my local wallet. Once confirmations started to arrive on that transaction, I moved a part of those bitcoins to a bitsquare wallet.

The amount was deducted ok from my first wallet, and I was able to use the amount in bitsquare for a deposit. But the status of the transmission/transaction is stuck in "sending" for two days. Since the coins i received the status has changed from "receiving" to "received" I'm thinking this one should have changed to "sent" by now. It says "seen by # peers", but nothing about confirmations.

My question then: Is this a problem? Should the status have changed to "sent" along with confirmations? Was there some process I needed to set up before sending?

(More on what I did): I am using MultiBit. After getting my coins with a few confirmations, I clicked "Send", wrote an wallet address from my bitsquare wallet, and clicked send. I read something about transaction fees and my wallet preferences is set to 0.1 mBTC (I wonder if this setting is ok).

Thank you in advance.

It's not saying that it's confirmed because it isn't confirmed. See Why is my transaction not getting confirmed and what can I do about it?

Your fee is pretty low at 40 satoshi/byte, so according to this chart, you should be using a fee 2.5x times higher if you want your transaction to confirm within a day.


Where to get the data for Transactions, Graphs as a Bitcoin Exchange Our team is planning to start our own Bitcoin Exchange where an end-user could Register, make transactions(Sell/Purchase bitcoin), keep their wallet and could see live Graph of all the listed crypto-currencies. And yes we do know what are all the legal, financial and technical requirements/challenges for this.

We researched about it a lot and found everytime that there are certain websites/Exchanges like blockchain.info that provide their own API for all such tasks.

However, if we want to create our own Exchange, we can't rely fully on any third party website. So, what my main question is that where do all these websites get their data from, whenever any transaction is made on their website, do they keep this record only to their selves(in their own DB) or is their any central entity of this whole blockchain web where this transaction needs to be registered also?

And where do these websites get data for their live graphs showing the current market value of all the currencies?

Any clarification of my query would be deeply appreciated.

whenever any transaction is made on their website, do they keep this record only to their selves(in their own DB) or is their any central entity of this whole blockchain web where this transaction needs to be registered also?

There is no central entity in a blockchain network. Such a thing would be antithetical to a decentralized cryptocurrency like bitcoin. A user may run a node and participate in the network, without having to trust any of it's peers to provide good information. Instead, the code validates all network interactions, providing cryptographic trust and guarantees.

Exchange services often run as centralized databases, this allows users to initiate many transactions (buying/selling on the exchange), without incurring network transaction fees. The exchange users trade off security (trusting a third party with their coins) for this convenience. However, there are other models that exchanges can use, it is up to your imagination to find a solution that balances trust and convenience in a way that your users will want.

  And where do these websites get data for their live graphs showing the current market value of all the currencies?

Exchanges generally define the market price of cryptocurrencies, this is not data you would pull from a third party. The market price would be discovered by users buying/selling on your exchange, if users push the price too high/low compared to other exchanges, then arbitragers will work to balance it back out.


Bitcoins did not arrive A few days ago I transferred bitcoins from www.blockchain.info to the Bitcoin Core - Wallet, but the bitcoin did never arrive, I made a Request and the address was: 15Yw9RpFY28cN1fjwQPQfqvxjGg9TXRLmB then I send the bitcoin to that address from blockchain but they never arrived.
My Bitcoin Core - Wallet is still synchronising with the network, it is 3 years and 21 weeks behind, is this the problem they didn't arrive?

Thanks,

dont worry

your 0.30811325 btc sent by this transaction are waiting for you

you have to synchronize your client to see and use your funds


What are the legal processes that someone would have to go through in order to get a Bitcoin exchange operational? One of the main perceived difficulties in getting started with Bitcoin is obtaining some in the first place.

Naturally, for an exchange to be accepted into the mainstream it needs to be a recognised and approved legal entity within the country it is operating in.

So my question is this - what are the legal processes that someone would have to go through in order to get a Bitcoin exchange operational?

If possible, it would be useful to have each answer target a particular country with suitable edits to become a solid reference.

At the present moment, no country recognizes bitcoin as actual "currency" so the laws for exchanging, buying, selling or trading in bitcoin are exactly as they would be for simply setting up a shop. For legal purposes, pretend bitcoins are any other object, let's say a chair...

If you set up a web site that exchanges chairs for USD and you sell enough chairs, you'll probably need a business license, it would probably be smart to incorporate your chair-selling business at some point as well. If you "mine" (assemble?) chairs then you have a cost of production and you make a profit. If the profit exceeds some amount which your state/country has established then you must pay taxes on those profits. Transactions which take place using bitcoin are essentially barter transactions: whatever laws would apply if you traded an equally-valued number of chairs for that XBox 360 apply to purchasing it with bitcoins as well.

I qualify all of this with "at the present moment" because it's all quite likely to change at some point. Bitcoin is only unregulated at the present time because lawmakers are, for the most part, unaware of its presence. Once they become aware, wheels turn slowly but eventually new legalities will inevitably spring up around the bitcoin community. If you intend for your exchange to last for more than a few years it may be worthwhile to set up shop offshore in a country like Panama, where the laws are more favorable to exchanging currency.

Edit: I must also mention that bitcoins may be recognized as a "value store" without being recognized as a currency. I am not a lawyer so this should not be taken as legal advice. If you have concerns about the legality of any service you wish to run, you should contact a lawyer - though even this is of questionably little help since at present there is not (to my knowledge) any precedent for just about anything we do with Bitcoin. As with all young technologies, expect legislation to spring up around it and expect things to change soon and often.


Why is CheckBlock called twice when processing a new block? Once the Bitcoin node receives a message with a new block, it calls the ProcessNewBlock function:

 else if (strCommand == "block" && !fImporting && !fReindex) // Ignore blocks received while importing
{
    CBlock block;
    vRecv >> block;

    CInv inv(MSG_BLOCK, block.GetHash());
    LogPrint("net", "received block %s peer=%d\n", inv.hash.ToString(), pfrom->id);

    pfrom->AddInventoryKnown(inv);

    CValidationState state;
    // Process all blocks from whitelisted peers, even if not requested,
    // unless we're still syncing with the network.
    // Such an unrequested block may still be processed, subject to the
    // conditions in AcceptBlock().
    bool forceProcessing = pfrom->fWhitelisted && !IsInitialBlockDownload();
    ProcessNewBlock(state, pfrom, &block, forceProcessing, NULL);
    int nDoS;
    if (state.IsInvalid(nDoS)) {
        assert (state.GetRejectCode() < REJECT_INTERNAL); // Blocks are never rejected with internal reject codes
        pfrom->PushMessage("reject", strCommand, state.GetRejectCode(),
                           state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), inv.hash);
        if (nDoS > 0) {
            LOCK(cs_main);
            Misbehaving(pfrom->GetId(), nDoS);
        }
    }

Inside this function, CheckBlock and AcceptBlock are called:

// Preliminary checks
bool checked = CheckBlock(*pblock, state);

{
    LOCK(cs_main);
    bool fRequested = MarkBlockAsReceived(pblock->GetHash());
    fRequested |= fForceProcessing;
    if (!checked) {
        return error("%s: CheckBlock FAILED", __func__);
    }

    // Store to disk
    CBlockIndex *pindex = NULL;
    bool ret = AcceptBlock(*pblock, state, &pindex, fRequested, dbp);
    if (pindex && pfrom) {
        mapBlockSource[pindex->GetBlockHash()] = pfrom->GetId();
    }
    CheckBlockIndex();
    if (!ret)
        return error("%s: AcceptBlock FAILED", __func__);
}

Inside the AcceptBlock function CheckBlock is called again:

if ((!CheckBlock(block, state)) || !ContextualCheckBlock(block, state, pindex->pprev)) {
    if (state.IsInvalid() && !state.CorruptionPossible()) {
        pindex->nStatus |= BLOCK_FAILED_VALID;
        setDirtyBlockIndex.insert(pindex);
    }
    return false;

Why is the CheckBlock function called two times when processing a new block?

I suspect this is an artifact of the way the code used to work. As to why it hasn't been taken out, it's probably just out of caution, or a "Don't fix it if it's not broken" mindset. Bitcoin Core coders are very cautious, and reasonably so since it's a piece of software that is the main interface to the network for many big players in the industry.

In addition, on master right now, CheckBlock contains a check at the beginning to avoid doing the same work twice. (Added in this commit.)

if (block.fChecked)
    return true;


does extended public key derivation go both directions I understand that unhardened extended public child keys may be derived from any unhardened extended public key without access to any private keys.

Is the reverse also true -- can a parent extended public key be derived from a child extended public key?

Is the reverse also true -- can a parent extended public key be derived from a child extended public key?

No. BIP 32 uses hash functions in order to derive the child keys. In order to be able to derive the parent key from the child key, you should need to be able to reverse the hash function, which is currently impossible (I say currently because some vulnerability could be discovered which allows it to be reversed, but that is unlikely to happen).

Furthermore, the child key derivation also involves calculating a public key from a private key (that private key is basically temporary and doesn't actually reveal anything about the child private key). You would need to reverse that too, but doing so is also currently impossible (it is theoretically possible with a quantum computer).


Bitcoin recovery - forgot my 12th recovery word for recovering my crypto account I have managed to forget the last (12th) mnemonic word to my crypto-account.
Could you please show me how I can find software with which I can enter recovery words from a file so that I can attempt recovering by changing the last word, which I do not know, from the dictionary.
I have read some answers but did not understood how to do it.

Disclaimer: there may exist software that does all of this automatically for you, but I'm going to provide a quick walk-through of the steps, which will allow you to compute this manually.
If you only need to recover the last word, then you're in luck, as there are only a small number of possibilities for what that last word could be. The Bip-39 word list has 2048 possibilities, but the last word in a seed phrase is partially determined by a checksum, greatly reducing the number of possibilities. Here is how to determine the possibilities for that last word:
Before beginning, it is worth pointing out that you are going to be handling sensitive data. If you are handling this data on a compromised computer, there is risk of your bitcoins being stolen (ie, the attacker would be able to get a hold of the sensitive data). It is best to use a computer that you trust to be clean, and that is not connected to the internet (at least, until you can recover your funds and move them to a new wallet which is not compromised by handling the seed data in this way). Do NOT use online tools to perform any steps which could potentially leak this sensitive data.
Step 1: reconstruct the binary seed, from the mnemonic.
Here is the BIP39 English word list. Take your mnemonic phrase, and look up the number associated with each word. Subtract 1 from that number, and write it down. For example, the word guitar is number 831, so you would write down 830.
(the reason we subtract 1 is that the word list linked to above starts at index 1, whereas the index used in the actual code starts at zero: 00000000000 (binary representation)).
Step 2: convert those numbers to binary numbers.
Each word represents 11 bits of entropy, which we will write out as a string of zeros and ones. Continuing from the example above, for the word guitar, the number 830 is 1100111110. Notice that this binary string is only 10 digits long though (10 bits), so we need to add another 0 to the start of the string, to make it an 11-bit number. So the binary number we will write down is: 01100111110.
Repeat this process for all the other words, again appending zeros to the front of the binary string as needed to make each number 11 bits long.
Step 3: Assemble all the binary numbers into one long binary string
This step is easy: you should have eleven binary strings, each one 11-bits (11 digits) long. Concatenate them into one long string (in the correct order, of course!).
Continuing from our example above, lets pretend that our seed phrase begins with the word guitar repeated eleven times. Our concatenated binary string would now be: 0110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110
This 11 word phrase comes from this 121 bit number, but in total, your 12-word mnemonic seed phrase encodes 132 bits of entropy. Of this 132 bits, the first 128 bits are random, and then the last 4 bits are a checksum.
So this means that the last word includes 7 random bits, and then 4 bits that are a checksum (of the 128 bit seed). This means you have 2^7 = 128 possible words to check.
Step 4: Compute the last word
We must iterate through the range of all possible 7-bit numbers, from 0000000 to 1111111. Each attempt will involve appending a 7-bit number to the end of the 121-bit number we built from the list of 11 words. So to begin, we can just append 0000000 to our number from above (the word guitar, repeated 11 times):
01100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111100000000
The next attempt would be:
01100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111100000001
And so on, until we reach:
01100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111101111111
For each of these 128-bit numbers, we will need to SHA256 hash the binary value, and then take the first four bits of the resulting output, and append those 4 bits to the end of the 128-bit number we started this step with.
To perform this step, we can use the command line tool shasum:
echo 01100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111100000000 | shasum -0 -a 256
This command tells your computer to take the 128 bit number, and run 'shasum' on it, -a 256 tells the computer to use the SHA256 hash function, and -0 tells the computer to interpret the input as a string of bits (this is important! If the string is interpreted in some other way, the resulting output will be incorrect).
The output of this command should be (in hex):
21bb0a0efc9fec48880509aa11fd1cc7f16a014b8bee65ab87b0505145e2a865 ^-
In this case we just want the first 4 bits of the output, which is conveniently just the first hex character of the string above: 2. (note that the ^- at the end of the output denotes that the input was interpreted as bits)
So we can convert the hex number 2 back to binary: 0010, and then append this binary value onto the end of our 128-bit binary string:
0110011111001100111110011001111100110011111001100111110011001111100110011111001100111110011001111100110011111001100111110000000000010
For this first attempt, we can see that the last eleven bits are thus: 00000000010. Converted to decimal notation, this is the number 2, which means the last word in our mnemonic is the word at index 2 from the BIP39 word list. BUT! Remember that the BIP39 word list starts at index 0, so similar to the above, we must add 1 to this number, leading us to the word at index 3, which is able.
So the first possible mnemonic would be:
guitar guitar guitar guitar guitar guitar guitar guitar guitar guitar guitar able
You can then input this seed phrase into some software that will accept 12-word BIP 39 seed phrases (such as Electrum wallet), and see what addresses the wallet generates for you. Note that you will also need information pertaining to the derivation path used by the wallet in question, for example was it BIP 44 or BIP 84? etc. I am aware of some tools that can help automate this step, for example see here or here. Ideally, you would know the first couple addresses of your wallet, so you can quickly check to see if electrum generates those same addresses, even in an offline environment. Ian Coleman's BIP39 tool will probably also be helpful, though you should be sure to download and run that webpage in an offline environment.
If you do not generate the correct wallet after this first attempt, you will need to increment the 7-bit number by 1, and then perform this step again. Possibly up to 128 times, but no more than that.


Does Cryptocurrency really need timestamps? Bitcoin is supposed to be a clock on it's own right so it always felt sketchy to me that outside time is referenced. Could bitcoin be aware of it's own block interval through something like uncle block rate? Could that allow it to do difficulty adjustment without reference to outside time?

I think the question isn't so much whether this is possible, but whether this is desirable.

The block rate limit has several functions:

Keeping the stale block rate low, so that the effort a collusion attacker has to do is not much higher than honest miners (per block).
Keeping validation on non-mining full nodes feasible.

The second of these goals is inherently hard to achieve without a clock (it could be integrated into your proposal by modulating block size based on the achieved block rate, but that again would introduce the need for a clock).

However, the first of these is also incompatible. A collusion attacker (someone who only mines on top of his own blocks, and ignores anyone else's), or a cartel of miners that collude against everyone else together, can set the block rate arbitrarily high while keeping the uncles rate zero (or whatever desired rate). If such an attacker drives up the block rate high enough, it becomes harder for honest other miners to participate, even when the attacker has less than 50% of the hashrate - the other miners are inherently disadvantaged by only seeing blocks with a delay (the ratio between delay and block interval affects their profitability).

So what this accomplishes is that it self-selects for a set of miners that can keep up with the intended uncle rate, which may be arbitrarily small. The desired property is subtly different: keeping the fork rate low when an acceptably distributed set of non-trusting miners can participate.


BIP 32 Public Parent Key -> Public Child Key Reading the BIP 32 section of how to generate Public child key from Public parent key, I got stuck in the following:

  The returned child key Ki is point(parse256(IL)) + Kpar.

As I could understand point(p) is the Elliptical Curve multiplication which will output X and Y coords, so how can I add them with Kpar? Also, it should return me a Compressed public key right?

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

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


How to get the last executed transaction? I work with a Wallet app and using the BitcoinJ for programming. I need to find the last executed transaction from the wallet. In the org.bitcoinj.core.Wallet class, I see there is a method getTransactionsByTime() that returns list of all non-dead, active transactions ordered by recency as List<Transaction>.

Will I access the most recent transaction with index 0 or the last index? I have made some experiments and I likely think that would be with index of 0. Because, it returns the sending info and I have done some recently, but, still weird as the amount doesn't match with performed.

While I have tried with the last index, I think that's obviously not the case as that's returns the info of the incoming transactions.

The way I find the most recent transaction,

    transactions.addAll(wallet.getTransactionsByTime());
    Transaction ts = size > 0 ? getTransactions().get(0) : null;
    this.transaction = addTransactionHistory(ts);

I print the transaction as the most recent one in console.

The first transaction in the list should be the newest one.

The best way to answer such questions is always to read the source code. getTransactionsByTime calls getRecentTransactions, and there is a comment:

  Returns an list of N transactions, ordered by increasing age.

You can trace down to find the critical minus sign that ensures this.

You can also find a test that explicitly verifies it works as documented.


Unconfirmed transaction for nearly 3 months Sorry but I am fairly new to this. I have qt wallet and have done quite a few transactions, but around Xmas time I placed a few payments that didn't go through. After  checking the web, many said just to wait and the coins will come back. But as it's now been 3 months, is there anything else I can do? Please be basic as I'm not that experienced.

What you need to do is find the transaction i.d.
There you will see everything if there is no confirmations after 3 months its just well strange , I think you can look for more answers also in bitcoin forums there are alot of people that can help there nad they answer usually instantly


How much bitcoin is 'lost', on average? As the title of this question states, how much bitcoin is 'lost' (the private keys are not stored by any individual, and so will theoretically never be spent again)? I'd be looking for a percentage per year, ideally. Are there any stats on this anywhere?

Does it matter that Bitcoin is a deflationary currency, since bitcoins can be lost but cannot created again? It seems like this might encourage hoarding.

Does it vary much from other coins? Is if very different from the amount of fiat currency lost or destroyed unintentionally?

You might want to check out this great comment by Pieter Wuille:

  There will never be more than 20999839.77085749 BTC.

  Reasons for this number being lower than the often-cited "21 million":

  The subsidy scheme (50 BTC per block, halves every 210000 blocks) is rounded down to satoshi's (0.00000001 BTC), which results in slightly
  less already (20999999.9769 to be precise).
  Due to an obscure rule in the original software (which is hard to change now), the 50 BTC generated in the Genesis block are actually
  unspendable, so only 20999949.9769 are left.
  There have been two occurrences (blocks #91842 and #91880) of duplicate coinbases, where the coinbase transaction of a block had the
  same hash as the coinbase of an earlier block, causes the generated
  coins to be "overwritten" in the database. This was made impossible
  later using BIP30 and BIP34, but the coins of those blocks are
  permanently lost (two times 50 BTC).
  Some times, miners have not claimed all fees/subsidy they could in a block, for example block #124724 only claimed 49.99999999 BTC subsidy
  instead of 50.01.
  Soon, with the introduction of provably-unspendable outputs (OP_RETURN), some will not be considered part of the set of spendable
  coins anymore (a total of 0.00835434 BTC currently).

Similar topics:

How Many Bitcoins Are Missing?
Bitcoin disappearence rate
Why doesn't Bitcoin return lost coins back into the block reward?
What could be the consequences of many bitcoins being lost out of circulation if people lose their wallets?
https://bitcointalk.org/index.php?topic=109117.0


Hunting missing Bitcoin from Multibit Classic I've spent days trying tons of things but hope someone can give a bit of direction.

So I purchased bitcoins, only a few in 2010, early. Then end of the year I imported them in to Multibit Classic 0.5.15. Thought great way to save it and deleted the old files I created with original purchase. Coins showed in the wallet. Then in 2013 I checked again and they where there, thought great. So I switched to SSD on my laptop and kept original hard drive as is.

I've now managed to get it back in the laptop, get the wallet files but low and behold balance 0 and I cannot see the imported key for the coins.

I've updated to Multibit Classic 0.5.19, synced around 7 times and still nothing.

Should the private key for importing the coins show in the wallet? So if I go export keys it should have two keys? Or is the wallet the only key that will be exported and I can import that in to Bitcoin Core even though the imported key is not showing in the export and the keys, bitcoin address, history nor are my coin balances are showing in the wallet? I had 0 transactions. Just imported, checked how many I have and value and left it only with install and again before changing HDD did I check and it then showed the balance. Will the keys only show after update or should they already show?

Any and all help appreciated.

Should the private key for importing the coins show in the wallet?

Most wallets will not show you the private keys unless you explicitly request them in the menu. This is for security, because the private keys are all you need to spend the coins sent to the corresponding address, so they should be kept as secure as possible.

  So if I go export keys it should have two keys? Or is the wallet the only key that will be exported

Your wallet can have multiple private keys in it, usually one private key per address (at least for addresses starting with a 1). So the number of keys exported will just be the number of keys in your wallet. Your bitcoins will have been sent to one or a few of these addresses, other addresses might have no coins sent to them.

  and I can import that in to Bitcoin Core even though the imported key is not showing in the export and the keys, bitcoin address, history nor are my coin balances are showing in the wallet?

Yes, the keys are all you need in order to import the addresses into another wallet program like Bitcoin Core. The wallet will then calculate the corresponding address, and look through the blockchain for transactions sent to that address (as long as you import with the rescan option set to true).

  I had 0 transactions. Just imported, checked how many I have and value and left it only with install and again before changing HDD did I check and it then showed the balance.

What do you mean you had 0 transactions? In order to have any coins, they must be part of some transactions. Do you mean no transactions are displayed now, but they were earlier?


What happens to the blockchain after the miner wins the puzzle? I have some problems understanding the flow of consensus mechanism, so far I know, In PoW when validating a transaction the miners will compete with each other to solve a puzzle, the miner who find the nonce first will get the chance to validate.

My problem is, I don't understand the process after this. I want to know what miners will do after solving the puzzle?

Thank you.

My problem is, I don't understand the process after this. I want to know what miners will do after solving the puzzle?

After miner A found the nonce, he broadcasts his "solution" to the network (miner B and miner C for example) and starts to build a new block and try to find the new nonce.

Miner B and miner C both validate the "solution". If it's a correct block, they add it to their local blockchain and broadcast it to others (Miner D, E, F...) and right after that, they do also build a new block and try to find the new nonce for that one.


When I pay, how is my balance checked, if I use different address every time? I know there are quite similar questions, but none have addressed my issue. Let's say I use Electrum wallet, that generates addresses & keypairs from seed. So for every next transaction I use different private key, public key & address. So (as I understand) when I want to buy something I send my address encrypted with private key to recipient, he decrypts it with public key & then checks the blockchain to determine if I can afford the transaction. But since I use different address for every transaction, how is that possible? I don't see way to connect current transaction to all that came before.

So (as I understand) when I want to buy something I send my address encrypted with private key to recipient, he decrypts it with public key & then checks the blockchain to determine if I can afford the transaction

Not quite the way it works. You just send the address, which is essentially the public key, to the person who is trying to do the paying. Given the address (more technically, references to times that address has been paid to on the blockchain before), anyone (not just the payee/payer) can verify that the transaction has the funds to spend.

And rather than sending the private key to show that you are the owner of the coins, you send a Digital Signature, which you need the private key to generate.

Your wallet reports your balance by looking at the list of times that you have been paid to before, which you have also not spent. This will be across many addresses. The network doesn't know which payments on the blockchain are yours, you have to reference a few of them when you want to spend funds, and prove you own the key to them with a digital signature.


Are non-SegWit transactions still malleable? SegWit was (amongst other improvements) introduced to fix malleability issues. Does that mean that non-SegWit transactions are still malleable? If so, what types of malleability could still happen in practice?

It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original.

To get this protection however, all transaction inputs must be segwit. As old style inputs by definition must be compatible with non-segwit software, their signature will contribute to the txid just as before.


Why does Bitcoin use separate change addresses? When you create a wallet, it creates one bitcoin address, correct?

When I send funds, it sends all my funds; the person I sent it to gets what I sent, and the change from the transaction is sent to a second address.

If that last one is true, why does the change get sent to a second address? Why not send it to the original? Wouldn't it be so much simpler if the change was sent back to one address, and you only had that one address?

Change is sent to a new address to improve your privacy and the privacy of the other Bitcoin users you interact with.  Let's imagine you receive a payment from Alice in one transaction; then you spend some of that money to Bob and the change is refunded to you.  Then, in an unrelated transaction, you send Charlie some bitcoins.

Because you keep all of your bitcoins in a single address and Alice, Bob, and Charlie know who you are, all three of them can now easily use a block explorer to look up how many bitcoins you have.  It's like letting your family, friends, bosses (past and present), local businesses, and everyone else you've ever transacted with know your exact current bank balance.

But who cares?  If you're like me and you don't have a lot of bitcoins, that may not be a big deal.  However, by reusing the same address for everything, you also reduce other people's privacy.  For example, lets say Alice pays Charlie (and Charlie also uses the same address for all transactions).

Now Alice knows your address from the previous transaction and Charlie's address for this current transaction, so she can see that you paid Charlie.  Charlie can do the reverse and see that Alice paid you---so by using a single address for everything, you may have reduced Alice and Charlie's privacy.

What Bitcoin Core and other high-quality wallets do is try to completely avoid address reuse.  That means they prompt you to create a new address for every incoming payment and they always pay change to a new address.  This helps keep transactions separate.

(broken image, original source)

If you and Charlie use unique addresses, Alice may not be able to tell that you paid Charlie and Charlie may not be able to tell you received money from Alice.  Also, it will be much more difficult for anyone to figure out exactly how many bitcoins you control.

(I say "more difficult" because there are still situations where Alice and Charlie may be able to identify the payments to/from you.  Using unique addresses is a significant privacy improvement, but it's not perfect.)

Using separate change addresses costs you nothing extra over returning change to the same address (that is, the transaction will be the same size either way, so you pay the same fee) and it may have a slight security advantage when used with software that is broken in particular ways.  However, the major advantage is that you improve your privacy and the privacy of everyone you transact with---and as someone who might trade with you some day, I thank you for using software that uses unique change addresses.

Note: Bitcoin.org's Choose Your Wallet page indicates whether a wallet uses unique change addresses by default, so anyone else reading this may want to use that page to select a wallet that improves their privacy.


Is a bitcoin UTXO divisible? In this video Andreas Antonopolous says an output is indivisible and therefore if a transaction smaller than the output is done, the rest is used as change and returned to your different address of same public key.

Is this true? How does lightning work with microtransactions then?

Is this true?

Yes, it is true. In very very simpler terms, think this to be in a way wherein someone sends you a coin worth that amount. In other words, if someone sends you 10 BTC, they are sending you a coin that is worth 10BTC, while when they send you 5 BTC, they send you a coin worth 5 BTC. So, while you are spending that money, you have to spend the entire coin. This is exactly the concept with UTXO. When you need to send some bitoins, you have to consume the entire UTXO amount and send the difference back to yourself through a change address.

  How does lightning work with microtransactions then?

Lightning transaction works in the same way. When forwarding a HTLC you subtract the amount from your own balance and lock that in the HTLC. Eg. Alice and Bob have a channel. in the present state, the commitment transactions of the channel consumes their channel funding transaction and outputs to (1) Alice_pub_key and (2) Bob_pub_key. Say Alice wants to send X satoshis to Dave. Alice creates a commitment transaction with Bob that consumes the entire bitcoins from the funding transactions of Alice and Bob's channel, and outputs to (1) X satoshi to htlc; (2) Alice's balance - X satoshi (3) Bob's balance.

Similarly when Bob forwards to Charlie, he will be deducting X satoshi from his balance in his commitment transaction with Charlie. Same with Charlie and Dave. When Dave provides the preimage, he will claim the amount in HTLC output in the commitment transaction with Charlie. Charlie will then claim that amount from his commitment transaction with Bob and Bob will claim the amount from the htlc output in the commitment transaction with Alice.


What are the exact steps for creating a transaction and having a valid block? I have read all kind of the articles and I understand almost all the concept from cryptocurrency. What I still don't understand is, what are the steps from transactions to a valid block.
On a post on this SE I found this:

Collects transactions from the network
Validates them, and doesn't allow conflicting ones
Puts them into large bundles called blocks
Computes cryptographic hashes over and over until if finds one "good enough to count"
Then submits the block to the network, adding it to the blockchain and earning a reward in return.

Let's take a practical example and please correct me if I make some wrong steps:

I send 10BTC to Batman.
Because I have send BTC, a transaction is created in system.
This transaction is send to all nodes from network (all users)
After transaction arrives to all users, the transaction is added in a queue where the miners take take their transactions.
A miner take transaction, process it (proof of work) and creates a block with more transactions.
After all the transactions are validated by miner, the new block is send in the network for check.

Now, questions:

How does each user check this blockchain (divide the blockchain and check each transaction if the transaction from the blockchain is the same with the one that he has (because first transactions are send to all the users from p2p network and after that are send in the queue to be process by the miner. This is how user is able to compare the transactions))?

I send 10BTC to Batman.
  Because I have send BTC, a transaction is created in system.
  This transaction is send to all nodes from network (all users)

That is correct so far

  After transaction arrives to all users, the transaction is added in a queue where the miners take take their transactions.

Yep, although its not really a queue because miners don't necessarily have to take the first transactions first. Its called the mempool, and its just a bit collection of them, with no enforced order.

  A miner take transaction, process it (proof of work) and creates a block with more transactions.

I'd just like to make it clearer that the proof of work is the name given to the hashing of the entire block, proof of work is not the verification of the transaction. Verifying the transaction doesn't take much work, only creating the block does.

  After all the transactions are validated by miner, the new block is send in the network for check.

After all the transactions are validated by the miner and the miner has found a valid proof of work block, that new block is sent to the rest of the network. Just valid transactions alone does not make a valid block. You are missing the idea of "Computes cryptographic hashes over and over until if finds one 'good enough to count'" that you mentioned. That is the proof of work.

  How does each user check this blockchain (divide the blockchain and check each transaction if the transaction from the blockchain is the same with the one that he has (because first transactions are send to all the users from p2p network and after that are send in the queue to be process by the miner. This is how user is able to compare the transactions))?

Users can just compare the transaction hash with the ones in the blockchain, because the hash is a deterministic "summary" or digest of the transaction. The same transaction will always have the same hash, but two different transactions will have different hashes. Full nodes always validate all the transactions in the new block when they receive it anyway, they don't just trust the miners.


How to run a private bitcoin network with low difficulty? I want to test and develop an open source mining pool. I don't have access to an ASIC miner or GPU, so I have to use my CPU to simulate mining and see how the pool really works.

The problem is the bitcoin testnet difficulty is so high and the CPU can't mine, produce blocks and get reward. I need a low difficulty private bitcoin in order to test the mining process. How can I achieve that?

Use regtest

Chain selection options:

  -regtest
       Enter regression test mode, which uses a special chain in which blocks
       can be solved instantly. This is intended for regression testing
       tools and app development.

  -testnet
       Use the test chain

Using this mode, you can manually mine blocks by issuing the following command, where nBlocks is the number of blocks to mine. You will need atleast 101 blocks before your first mining reward becomes available.

bitcoin-cli generate nBlock


How do I create a new genesis block for an altcoin? I'm trying to clone the Blackcoin sourcecode just for the hell of it but I can't seem to generate a genesis block. I can do it on normal coins, but not here. The Blackcoin developers seem to have shifted a lot of code into weird places.

For example, all of the coins major parameters are in chainparams.cpp. However, there is no code in the link above or in main.cpp to create a genesis block.

How do I make a genesis block for this coin?

They just removed the gen-generation part from the sources as it's not needed after the genesis being generated and already implemented (hardcoded) into the sources.


ElectrumX server as a Tor hidden service I am trying to run an ElectrumX server on my PC. I run it on a docker container with the following Dockerfile configuration:
FROM python:3.7-alpine3.11
LABEL maintainer="Luke Childs <lukechilds123@gmail.com>"

COPY ./bin /usr/local/bin
COPY ./VERSION /tmp

RUN VERSION=$(cat /tmp/VERSION) && \
    chmod a+x /usr/local/bin/* && \
    apk add --no-cache git build-base openssl && \
    apk add --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/v3.11/main leveldb-dev && \
    apk add --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/testing rocksdb-dev && \
    pip install aiohttp pylru plyvel websockets python-rocksdb && \
    git clone -b $VERSION https://github.com/kyuupichan/electrumx.git && \
    cd electrumx && \
    python setup.py install && \
    apk del git build-base && \
    rm -rf /tmp/*

VOLUME ["/data"]
ENV HOME /data
ENV ALLOW_ROOT 1
ENV DB_DIRECTORY /data
ENV SERVICES=tcp://:50001,ssl://:50002,wss://:50004,rpc://0.0.0.0:8000
ENV SSL_CERTFILE ${DB_DIRECTORY}/electrumx.crt
ENV SSL_KEYFILE ${DB_DIRECTORY}/electrumx.key
ENV HOST ""
WORKDIR /data

EXPOSE 50001 50002 50004 8000

CMD ["init"]

I want to advertise the ElectrumX server as a Tor hidden server. My bitcoin-core is also reachable by an .onion address: j3zla562edof65jn.onion. How can I configure the ElectrumX hidden server? What will be the .onion address of the server? I cannot access the ElectrumX from my electrum client using j3zla562edof65jn.onion address. Also, the status of the server is Closed in the Servers list.
Many Thanks.

I found the answer. It was not too hard. You should make a separate Tor hidden service for the ElectrumX server. The following two links helped me:

https://www.reddit.com/r/Electrum/comments/ggmduo/electrumx_over_tor_configuration_help/
https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service

To create a hidden service, you should take the following steps:

You must have tor (at least version 0.2.7.1) installed on your host. You don't need to install it on the docker container.
To establish a hidden service, open torcc file (probably you can find it at /etc/tor/torrc). Add these lines to the file:

HiddenServiceDir /var/lib/tor/electrumX_service/
HiddenServiceVersion 2
HiddenServicePort 50001 127.0.0.1:50001
HiddenServicePort 50002 127.0.0.1:50002

Restart tor by running this command: sudo service tor restart
To see the hostname of the new hidden service (electrumX_service), run sudo cat /var/lib/tor/electrumX_service/hostname. you will see the hostname. For example, my hostname is dpojvtzgm5dcg5ds.onion.
Now, you should set the REPORT_SERVICES environment variable in the ElectrumX container. To do this, you can set it at the beginning, when you want to run the container. I use the following command to run the container: (use the recently created hostname address for the REPORT_SERVICES environment variable.)

docker run --name=electrumx --rm --network=host -v /home/taghi/Taghi/docker-electrumx/electrumx:/data \
-e DAEMON_URL=http://MY_BITCOIN_CORE_USERNAME:MY_BITCOIN_CORE_PASSWORD@127.0.0.1:8332 \
-e COIN=BitcoinSegwit \
-e REPORT_SERVICES=tcp://dpojvtzgm5dcg5ds.onion:50001,ssl://dpojvtzgm5dcg5ds.onion:50002 \
lukechilds/electrumx

you can connect to the ElectrumX server by an Electrum client to check if it is working correctly. Furthermore, you can add it to this Server list .

Remember: I have exposed 50001, 50002, 50004, and 8000 ports in the above Dockerfile.


How to perform atomic swap Bitcoin-Litecoin I am running Bitcoin and Litecoin nodes fully synced on testnet.Can I perform atomic swapping by using this networks?

I heard it can be done through HTLC(Hash Time Locked Contracts). How can I do exactly by HTLC and trying to go deeper in to HTLC?

Thanks.

You would need to find another party to do the swap. An example:

Alice and Bob have accounts on both chains. Alice has Litecoin that she wants to exchange into Bitcoin. Bob has Bitcoin that he wants to trade for Litecoin.

Alice tells Bob that she is willing to give him 2.5 Litecoin for 1 Bitcoin. Bob agrees. They both agree that Alice will publish a contract on the Litecoin blockchain that transfers 2.5 Litecoin from Alice to Bob.

Once the Litecoin contract is published, Bob examines it. He sees that the parameters are to his liking, so he publishes a contract on the Bitcoin blockchain that transfers 1 Bitcoin from Bob to Alice.

Alice examines the Bitcoin contract, and likes what she sees. She uses the preimage that she used to build the Litecoin contract to unlock the 1 Bitcoin. Bob is no longer the owner of the 1 Bitcoin.

When Alice used her preimage, that preimage was published on the Bitcoin blockchain. Bob sees it, and uses the same preimage to unlock the 2.5 Litecoin on the Litecoin blockchain.

That example is a simplified version of the typical scenario, but I hope it helps you see the coordination required to do an HTLC.

A little more detail into the mechanisms can be found on a writeup I did for HTLCs between the Bitcoin and Bitshares blockchains. It can be found at http://www.jmjatlanta.com/index.php/2018/09/27/bitshares-and-hashed-time-lock-contracts-htlc

If you are looking for more technical how-to, you can use the following resource:

HTLC (Hash Time Lock Contract) using bitcoin-qt

I use the libbitcoin library for BTC. A tutorial that can get you started with HTLCs using that library can be found at http://aaronjaramillo.org/libbitcoin-cross-chain-swaps-with-htlcs


Are there immediate plans to make Bitcoin more accessible to Forex traders? Most people trading in foreign currencies are not technical, and will not learn how to operate the "technical jungle" that is Bitcoin.

Are there any known plans to expose Bitcoin to Forex while staying in their comfort zone - e.g. any existing foreign exchanges that plan to support Bitcoin (instead of forcing them to go to websites specializing in Bitcoin?)

As far as I'm aware most bitcoin exchanges don't adopt fiat currency as it requires them to be licenced with the money markets.

The same goes for the forex markets which exist such as IG Index or Capital Markets. The situation which would allow them to trade bitcoins for money is not suitable as it's not recognised as legal tender and organisations such as the IMF would not accept trading on licenced exchanges.

It's rather safe to assume for major players in the money markets would be unable to adopt bitcoins due to the red tape involved.

A small quote from the best exchange I am on

"Financial Regulation

Our business and services are buying, selling and trading virtual goods and commodities. We are not currently regulated as a financial institution."


Custom bitcoin confirmation process I am implementing a payment module for bitcoins.

I have the following case. I need customers to be able to pay in bitcoins. But for some reasons I cannot use existing solutions like Bitpay.

Therefore I have thought and ended up with the following solution.

We have a private key wallet of HD type, so we can generate child addresses from our master key.
When a user tries to pay in Bitcoins we are generating a new address and display it to the user.
We associate an address with an order id
A daemon running in background is checking pending orders requesting information from Blockchain for a concrete address and checking whether this address received amount equal to an order total sum.
In case there are more than X confirmations we are setting a status of an order to PAID

I wonder whether this is acceptable solutions or maybe there are some better ways to implement custom bitcoin payments ?

I would be great for any suggestions and help.

Thanks

There are existing solutions that handle payment processing for you. You can use BTCPayServer which has an API that is similar to BitPay's API.


how to setup an ardor childchain bundler via the command line on a ubuntu server? I have setup a testnet ardor node on the command line and its synced to the testnet ardor blockchain. I want to now create an always on bundler to bundle transactions of the ignis childchain via the command line. What is the command to run a bundler for ignis?

You can use any script which invokes the startBundler API but note that you will need to submit the passphrase to the node in order to start a bundler so you need to somehow protect the data in this script.


Why does this transaction results in only 2 unspent output (and no spent output)? This transaction is from one of the latest block. However I don't understand why it seems to be just dividing a single transaction without being spent and transferred to someone else.

I don't understand why it seems to be just dividing a single
  transaction without being spent and transferred to someone else

Only Unspent tx i.e UTXO could be spent, and here in your case this  tx is UTXO which after spending to addresses

13MDsVCs3AvSxZxjWUwty2gthPAXkYf6wb - (Unspent) 0.00928291 BTC
1CPp812W35rarR45CS6EYxdC4JazR4H9Wn - (Spent) 0.00231133 BTC

now becomes spent tx

  Why does this transaction results in only 2 unspent output (and no
  spent output)?

This is because lets say this is  your address: 1CPp812W35rarR45CS6EYxdC4JazR4H9Wn where you want 0.00231133 btc, so its one of the output address.
So after sending 0.00231133 to your address leftover balance i.e 0.00928291 need to be stored some where so in that case  13MDsVCs3AvSxZxjWUwty2gthPAXkYf6wb becomes your change address where remaning btc left after spending utxo is sent. Thats why you have 2 unspent op


How to pass passphrase to BTCRecover? I try to use BTCRecover, because I can not recover my old Copay app. All I have

12 word
a BTC address
passphrase (a good guess on it)

Checking this video: https://www.youtube.com/watch?v=8q65eqpf4gE
https://github.com/3rdIteration/btcrecover
Installed the environment.
I did not found any example where all the 3 info is passed. Usually script input is

12 word
a BTC address

But when I installed years ago Copay, I did set a password also. As I remember. :)
My expectation is to find out what was the derivation path at that time with Copay, maybe it was different then now. Basically I would validate all the 3 source are ok.
1: Am I on the right track?
2: Which scipt / setting I need to pass the passphrase?
I started based on this example:
python seedrecover.py --wallet-type bip39 --addrs bc1qv87qf7prhjf2ld8vgm7l0mj59jggm6ae5jdkx2 --mnemonic "element entire sniff tired miracle solve shadow scatter hello never tank side sight isolate sister uniform advice pen praise soap lizard festival connect" --addr-limit 5

Passwords and Pass-phrases

I have [...] passphrase (a good guess on it)

...

when I installed years ago Copay, I did set a password also.

I'm not 100% certain that you mean two different things by the words I highlighted. People play fast and loose with these words.
Password or Pass-phrase can refer to the same thing or to different things.

A Password or Pass-phrase can be used to protect the wallet. Typically by using it, directly or indirectly, as an encryption key to encrypt the wallet contents. This is not needed when using the seed-phrase to recover control over money and create a new wallet.

A BIP-39 pass-phrase is, as I understand it, simply additional words appended to the seed-phrase. This pass-phrase is chosen by the user, the seed-phrase is typically generated randomly by the wallet, not chosen by the user. The seed-phrase is sometimes called a recovery-phrase or backup-phrase.

So if your pass-phrase is just a multi-word password, as in case 1 above, you can ignore it.
BTCRecover
See https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md

BIP-39 Passphrases
Some BIP-39 compliant wallets offer a feature to add a “BIP-39” or “plausible deniability” passphrase to your seed (mnemonic),

It seems to me that you use the bip-39 option and just add the BIP-39 pass-phrase to the token list, but a careful study of the documentation ought to make this clear.