Bitcoin mining problem is to find a string s (hash of previous block + Merkle Tree Hash + nonce) such that sha256(s) has n leading zeros, where n determines the mining difficulty.

First a clarification. string s (block header) will include hash of previous block header, merkle root, nonce, target bits, timestamp and nonce.

  So if N=6393023717201, how do I expect 63,93,02,37,17,201 number of zeroes in 16bit length string?

That is not how difficulty is represented. We start with the genesis block that has a difficulty of 1. At that difficulty we needed to find the block hash that was less than 0x00000000ffff0000000000000000000000000000000000000000000000000000. The current target hash is finding block header less than 0x0000000000000000002c071d0000000000000000000000000000000000000000. So your difficulty number is genesis block header hash target/current block header hash target. That's how you get 6393023717201.863.

Refer here for more info as to how block header hash target is determined using target bits that are in the block header.

  Why difficulty decreases at some point in time?

In bitcoin the difficulty keeps the average block time at 10 minutes. If miners start using sophisticated instruments (eg. ASIC chips) that find the solution to the block header faster than 10 minutes, then every 2016 block the difficulty is adjusted so that the time needed to mine blocks increases. If miners start lowering their investments in sophisticated instruments so that average block mining time over 2016 blocks is more than 10 minutes, then the difficulty is lowered so that block mining time is faster. All of this is done so that we converge to 10 minutes as the average block mining time.


safely delete the blockchain from .bitcoin directory

Delete the "blocks" and "chainstate" directories.


Yes, multiple transactions building on each others' outputs can be in the same block. However, they have to be in the correct order inside of the block.

The order of transactions in a block can be freely chosen except for two rules: the coinbase transaction must be the first transaction, and parents must be before children.
Note that the order of transactions in blocks is explicitly specified by the positions of the leaves of the Merkle tree.


how to see my private key bye decrypted wallet.dat

If you are using Bitcoin Core:
1 - Go to window > console
2 - Type listunspent
3 - You will get a list of addresses with the spendable amount
4 - Copy one of those addresses
5 - Type dumpprivkey pasteYourAddressHere


How do you choose the correct fee with Bitcoin Core?

Bitcoin Core has updated their fee estimation logic several times in the past few years, another patch coming up shortly in Bitcoin Core 0.15.0. If you aren't running a current version of Bitcoin Core, you should first update your software to the most recent version.

If the problem occurred with a recent version of Bitcoin Core, you should consider checking different resources on the web to get a feeling for the current fee level on the network in order to sanity-check the fee level suggested by Bitcoin Core during the transaction generation process.

Some such sites are:

https://btc.com/stats/unconfirmed-tx
https://bitcoinfees.github.io/
https://bitcoinfees.21.co/

Another option would be to use the RBF feature, although this is currently only available for crafting transactions via commandline. A pullrequest to support it in the GUI is in the makings, I think that Bitcoin Knots (Luke Dashjr's client) already supports it in the GUI.


How do you generate a qr code for a new address and check for incoming payments from the command line?

Using Bitcoin Core, I would combine getnewaddress, qrencode, and listtransactions.
> bitcoin-cli getnewaddress ( "label" "address_type" )

Allows you to generate a new invoice address and label it to identify the current purchasing process. It returns a string with the newly generated address which you can then decorate according to the BIP21 URI scheme to allow operating systems to recognize it as a Bitcoin address, and output that the resulting string using a quick response code tool such as qrencode.
Finally, you would poll your wallet for new transactions using
> bitcoin-cli listtransactions ( "label" count skip include_watchonly )

which will give you recent transactions relevant to the wallet, or alternatively allows you to specifically filter by the label you previously attached in getnewaddress. The rpc descriptions I linked are for Bitcoin Core 0.21.0, but older docs are available through the same site.
Note that versions preceding Bitcoin Core 0.17.0 (released in October 2018) are past their End of Life date in their maintenance cycle. I would emphatically recommend using a newer version of Bitcoin than what may have shipped with Ubuntu 16.04.


Simple cryptsy market price observer HOW?

Your problem is that you only get the market data once, then keep displaying the same values.  Move your call to cryptsy.getMarkets() inside your while loop, like so:

public static void main (String [] args) throws CryptsyException, InterruptedException{

      Cryptsy cryptsy = new Cryptsy();
      cryptsy.setAuthKeys("<authkey>", "<authpass>");

      while(true){
         markets = cryptsy.getMarkets();
         for(Market market : markets) {
            DecimalFormat df = new DecimalFormat("#.########");
            if(market.label.equals("DOGE/BTC"))
               System.out.println(market.label + "   " + df.format(market.last_trade) + "   " + market.current_volume );
         }
         TimeUnit.SECONDS.sleep(5);
      }
   }


Can I buy Litecoin with Paypal or a credit card?

Bitocin and Litecoin have the same problems when trying to buy them with funding methods that allow chargeback.This is mainly because of Paypal’s TOS (Section 3.7 here) and the fact that your can't chargeback Liteocin since it is considered as cash.

Having said that there are still a few ways you can buy Litecoin with Paypal or a credit card.

Use VirWox to buy SLL with Paypal and then transfer that SLL to BTC (has high comission, transaction can take between 1 hour to 2 days). After that transfer the BTC to either Vircurex or BTC-E and purchase Litecoins with them. Complete process explained here.
You can use Local Bitcoins and perhaps find someone in your area to sell you Bitcoins with cash or even someone not in your area to sell you Bitcoins with Paypal or a credit card and then use these Bitcoins to buy Litecoins at the same exchanges mentioned before.
If you’re only into trading Litecoins for their volatility and not actually keep them you can use platforms such as Plus500 to trade CFDs. However CFDs are for more experience traders and your capital is at risk so take that into account.
You can also buy Litecoins with Paypal or a credit card on Ebay. As long as they are sold with an actual physical product (meaning they are stored on a USB for example). Be ready to pay a high commission though since sellers have to insure themselves from soaring Litecoin prices.


Are the transactions displayed on "BitListen" really accurate?

Yes it's real. If you don't believe it you can simply look at a block explorer and view many other transactions of similar sizes.


Multisig and Bitlicense???? Can a business even be a custodian?

This falls into an explicitly gray area, as called out by a number of people when bitlicense was first adopted. For example, see; https://twitter.com/twobitidiot/status/606157758224834561 and the linked tweet. Also see: https://coincenter.org/2015/02/our-initial-thoughts-on-new-yorks-revised-bitlicense-proposal/

Practically, if you're not acting as a custodian, then it's unlikely to be enforceable, and they will leaver you alone. If you are, effectively acting as a custodian over the funds, it is possible that NY could choose to go after you - and they have expensive lawyers.


a node has to own at least 51% stake of all the network.

This is correct. Note: you should own 51% of network, not 51% of emission.

  only a single miner can append a block at the same time

Not true, but it does not matter.

  how can fork happen to make the double spending attack?

Assume you have large stack.

backup your database at some checkpoint
sell your stack for "anything else"
restore from backup and create a private network which is not connected to main network
leave your chain mining until the cumulative difficulty become larger than in main network
connect your network to main net and force it to reorganize mainchain to your chain where you still have your funds and 100% mining rewards

voila


bitcoind connection refused error with curl

Try setting rpcbind to the same ip address as rpcallowip. I believe the behavior of those options changed recently with 0.18.0, https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.18.0.md.

  The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).


Can I monetize "crypto" using asset backed securities?

A friend of mine wants to create "tokens" signifying the completion of certain corporate milestones, e.g., the acquisition of X customers,

This is possible, Bitcoin (and some other cryptocurrencies) allow users to create 'non-fungible tokens', which can be individually tracked through the blockchain history.

  and then "monetize" these "crypto" tokens as "asset backed securities."

An 'asset backed security' generally refers to:

  a financial security collateralized by a pool of assets such as loans, leases, credit card debt, royalties or receivables.

So I'm not sure how a 'corporate milestone token' would satisfy this definition. If there were some monetary reward available for redeeming said tokens, perhaps that could loosely fit, but in that case this seems like a very contrived system to build. Why not just issue the reward directly to the recipient in the first place? If you have to trust the corporation to pay out your reward, why not just trust them to keep a version-controlled excel spreadsheet with all of the data stored in it? That would be a much cheaper and easier system to implement.


What are the web3py equivalent for communicating with bitcoin in Python?

Libraries like Web3py or Web3js are connected to a node using JSON-RPC behind the scene. I am not aware of any library for bitcoin like Web3py. But Bitcoin do provide JSON-RPC interface, which you can use to perform these operations.


Is there a uniform measure of "difficulty", that when multiplied by price, will give "profitability of one hour of mining"?

The standard formula to determine the average profit per day for a given MH/s miner on a given blockchain is as follows:

(S/(D*4295))*60*60*24*R*P

Where S is the speed in MH/s rating of the miner, D is the difficulty rating, R is the reward (50 BTC/block for Bitcoin) and P is the price in USD of a single coin.

That I know of there is no standard profitability measure but it would be easy enough to create one given standard values of S. If for example we define the standard as S=100 MH/s then we could easily compare the profitability of mining various blockchains in the resultant USD calculation.


Reports of Cryptocurrency Exchanges faking volume trade data. Where can one find this report?

All online roads seem to lead to https://www.blockchaintransparency.org


How do I lookup the details of a transaction, given the transaction ID?

I found where GDAX shows the transaction hash!

Visit https://www.gdax.com/accounts
Click a coin on the left (BTC, BCH, ETH, or LTC).
Instead of staying on the "History" tab (which is probably where you see Transfer ID for each transfer), click "Transfers" in the top right.
Then click each "withdraw" row to expand it, and you'll see its transaction hash.

For example, I'm able to find the hash of an LTC that I just transferred, and then I can browse to https://bchain.info/LTC/tx/4a857bc76d31c801dbc1aac33c4940cd11401f7f7401dfd6e05dfcf43af8867e and see that it has already been confirmed twice.


Transaction fees with Dogecoin or Ripple for small amounts

Fully understanding where you come from, IHMO you should choose the crypto currency which most of your potential customers keep in their wallets anyway. Especially when it comes to small amounts (as you say) hardly anyone will be willing to go to an exchange first and trade 0.0005 BTC into a different coin only to pay you.

I would suggest to take a look at the Lightning Network (https://en.wikipedia.org/wiki/Lightning_Network).


Indeed, the current state of the channels is not announced (it is allegedly hidden for privacy purposes). Therefore, A does not know if a route has enough capacity until he tries to make the payment throught that route.

A recent study claims that success rate is around 80% for USD 1.2, but only about 1% for transactions larger than 200 USD.

Related question: In lightning network, is the balance publicly anounced in realtime?


Why are Virtual Machines used in Ethereum?

note: I might be wrong

The EVM is actually the core of Ethereum. All contracts are written in EVM bytecode. This doesn't mean that Ethereum includes an actual virtual machine in the sense of Hyper-V, Vmware or Xen. It contains something[*] that can execute EVM bytecode (that something can either be interpreter, jit or aot). So, VM in this case is just a name for emulating the bytecode.
Without the EVM, all transaction types would have to be hardcoded (this would limit capabilities, but would also be much safer).
Why do you think that Bitcoin does not have a VM? It actually has. Script is Bitcoin's bytecode, you can read more about technical details here: https://en.bitcoin.it/wiki/Script


How to solve Blockchain 20 address gap-limit problem?

Yes the gap is an issue with the HD wallet.  Blockchain made a blog post about working with this issue. See here: https://blog.blockchain.com/2016/06/15/receive-payments-api-update-address-gap-limits/#more-9024

Let’s say you get paid to the first address, address 1 — the wallet will look ahead 2-21 addresses to see if there are any additional funds or transaction history in those addresses. If it doesn’t find anything, it will stop looking. So, if you get paid to address 22, the wallet software will not see the funds because it stopped at 21. However, if you get paid to address 2, the wallet software will look ahead addresses 3-22, see the funds that were sent to the address 22, and then look an additional 20 ahead (addresses 23 – 43).

Starting from August 1st, 2016, we will respond to API requests that would push you past the 20-address gap limit with an HTTP error, and we will not generate any new addresses for your xpub until we detect a payment that would close the gap below that limit. This ensures that you will never have unreachable funds through the use of Receive Payments API V2, but might lead to not generating addresses when your users request them.

You can call the checkgap API via the following endpoint:

https://api.blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}

You’ll get a JSON response that looks like:

{ "gap": 1 }

This gap value represents the difference between the index of the most recent address paid to, and the most recently-requested address. If that value is 20 or greater, funds paid to any further addresses created will be hard to access until earlier addresses receive funds.


What would happen to the Bitcoin network if all miners simultaneously stopped their mining efforts?

Transactions would never acquire any confirmations and the network would be essentially useless. In principle, people could still accept transactions if there were no conflicting transactions, but anyone could perform a transaction and then undo it if they wished to do so.


Coinbase (or other service) conversion to fiat: how is that recorded in the Blockchain?

If I use a service such as Coinbase to buy Bitcoin, Coinbase generates
a BC address for me and that's recorded in the blockchain.

No, it's not recorded in the blockchain, but in their own systems, basically they associate that address to your coinbase account

If I convert to fiat (i.e., USD) all BC at the address and send that
USD to my bank account, Coinbase records that in my account. Since my
account with Coinbase is private, only I know I have cashed out.
But how is that "cash out" and transfer to my bank account recorded in the blockchain
Does the blockchain show it is a cash out from Coinbase?

the address(es) coinbase create for you, are just used to know, in case you deposit funds on your account, where you can send that money to, but it's not used for anything else
Basically they associate in their own system that :

your account A is associated to AddressX
when you want to deposit funds to coinbase, you have to send BTC to that AddressX

Coinbase then have software that monitor addresses they owns, like AddressX (because not your key, not your money, so technically AddressX is coinbase address,not your)
When they see that a deposit has been done on your AddressX, they update their system (aka their (R)DBMS where they store their users data) and add the received BTC to your Account balance, then very likely they move funds from AddressX to a cold storage wallet (but this may vary) because BTC rarely are left on the deposited address but moved somewhere safer
When you then want to convert, they have just to send FIAT to your bank account and update your account balance, without moving any funds at all (even if I think they move funds not associated to users somewhere else, but this is just a guess and anyway it's an implementation detail)
Basically your AddressX can just be considered like a door to enter in their system, nothing more, and the balance that you see listed on that AddressX is not guaranteed to be the value you have in your coinbase account.
--
A proof that a strict relation between AddressX and your Coinbase account balance
doesn't exists is easily verifiable by looking a transaction when you WITHDRAW from coinbase to some other BTC wallet, in that case you'll see that the INPUTS used to generate the transaction to move funds, aren't related to AddressX


I believe you are correct, both about the fact that height-based logic came first and time was added later, and the fact that this is a hard-forking change. A transaction with a locktime > 500000000 would not have been acceptable before the change, but possibly valid after.

Of course, given that no such transactions occurred (to the best of my knowledge), it isn't exactly a fork; but it was a change that could have led to one.

Also, before the removal of OP_VER, technically speaking every new release had a hard forking change of this nature.


Yes, it uses a Winternitz OTS scheme. It is believed that Lamport signatures would still be secure against a quantum adversary.
No merkle signature scheme used with IOTA for transactions, as the result of a number of design and security decisions, for instance, signature size. It was a conscious decision to not use a stateless merkle scheme like sphincs. So yes, you should always transfer change to a new address. The implications of reusing a private key in a lamport scheme is that each reuse halves the security level of the signature (assuming a random message).


What is the counterpart of mining when using blockchain for traceability?

The Bitcoin blockchain achieves immutability through proof of work mining. It is considered immutable because many economic actors commit their computing power to finding new blocks. If not "enough" people are mining, the blockchain is not immutable. Recently both the Bitcoin Gold and the Ethereum Classic blockchain have been manipulated through a 51 % attack so these weak (i.e. low hash rate) blockchains are not immutable.

If you do not want to worry about having enough miners, you could consider building a token on top of either the Bitcoin blockchain or on top of the Ethereum blockchain (e.g. an ERC20 token). On Bitcoin, the Omni protocol allows for you to build your own token which is transferred on the Bitcoin blockchain. This means that you have to pay transaction fees (to the Bitcoin miners) to transfer the tokens but the benefit is that you will not have to worry about a 51 % attack (other people are trying to prevent that).

If you want non-fungible assets (each with their own ID attached), the Ethereum protocol standard ERC721 is made for this purpose. I am not aware of a similar solution on top of the Bitcoin blockchain.

If you want something else, like a more general, immutable log system that you can define yourself, you may have to write your own contract in Solidity (for the Ethereum blockchain) and only allow specific addresses (one for each member of the production chain) to write to this log.


You could download a full client of bitcoin cash like Bitcoin ABC (https://www.bitcoinabc.org/).
After that you can import your private keys from the paper wallet with the console (help > debug window > console) and enter

importprivkey <yourprivatekey> "label of address"

The optional "label of address" is just a description for you and not visible for anyone else.

After entering the importprivkey command, the wallet has to rescan the wallet for transactions, which may take a few hours depending on your system. After that, your address is fully spendable from within your wallet.

If you want to import multiple private keys, you can disable the rescan option until you entered all private keys with an additional argument. For example, to import 3 private keys you can use 2 times "false" to skip rescan and on the last import "true":

importprivkey <yourprivatekey-1> "label of address 1" false
importprivkey <yourprivatekey-2> "label of address 2" false
importprivkey <yourprivatekey-3> "label of address 3" true

Beware: Ensure that you claim your Bitcoin (BTC) first, and only after successfully sent them to another address use key for claiming your Bitcoin Cash (BCH), because BTC is way more valuable than BCH and I don't know how safe Bitcoin ABC actually is.

This procedure is a bit cumbersome, because you need to download the whole blockchain. But you are not dependent of any third-party applications or websites and don't reveal your private keys to anyone online.

This method can also be applied to any other Bitcoin Fork, assuming that there is a QtWallet for that Fork available.

After claiming your coins I would suggest to never use the address again. Get a new Paper wallet address if you want to use one again.


At what rate are new addresses appearing in the blockchain?

Blockchain has a chart of new addresses per day:

http://blockchain.info/charts/n-unique-addresses


testnet server won't get any btc from TP's TestNet Faucet. what is the reason?

I've just tested TP's faucet and it worked (green success text).

Are you sending to a testnet address (begins with m, n, or 2)? I'm thinking you may be inadvertently using Mainnet or Regtest mode (beginning with 1 or 3).

Ensure your Bitcoin.conf file has testnet=1 in it, or use the -testnet flag on the command line. Also be certain your blockchain is fully synched (this will take many hours, unlike regtest mode)

Go into BitcoinCore's client, and try getnewaddress in the console (help > console). Then copy/paste that address into the faucet, complete the CAPTCHA, and the coins will have been sent. You will need to have a completely synched blockchain before the coins will "appear".


How to get the number of Bitcoin transactions every 30mins using API in python?

You can use the blockchain.info api (https://blockchain.info/api) and then track in your database the different number of transactions based on any time you would like.


How does a miner put his vote for certain BIP?

See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.
As for the actual mechanism used to signal, a number have been used in the past:
Time based: BIP16, BIP30
Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.
Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's scriptSig field, which is otherwise free for miners to put anything in.
Block-version signalling: BIP34, BIP65, BIP66
A later generation of softforks used the block header's nVersion field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).
Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number of higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.
Versionbits-based signalling: BIP68/112/113, BIP141/143/144, BIP91
The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, BIP9. It specifies using one specific bit of the block header's nVersion field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.
Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.
The future?
There are a variety of mechanisms available these days, and there is active discussion on what to use for the (likely) next softfork, specified in BIP340/341/342 (Taproot). This includes a variant of the BIP9 versionbits mechanism, called BIP8. An article on the various possible schemes can be found here.
Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).


They're exactly the same number; one is written in little endian notation and the other is big endian.  Notice that the bytes (two-hex-digit pairs) are exactly reversed from one to the other.

Block explorers like blockchain.info usually expect big-endian for block hashes.  The proof-of-work requirement means that the most significant bits have to be zero, so big endian makes it easier to see this.


Blockchain for internet-of-things or is there any mining algorithm that can be utilized in low-computational power devices preserving security?

No, not in a fully decentralized way.  Hash-based methods (like what Bitcoin uses) will always be more efficient on more efficient hardware.  Proof-of-stake methods can't be fully decentralized.
No, hardware can't prove its capabilities in a fully decentralized way.  It is possible for a device to prove its maximum distance from you using the speed of light---if you send it a ping and it replies in n seconds, you know it's within n times 300,000 kilometers of you.  You can use similar hacks to prove other things---but you can't trustlessly export that proof to other users on the network you don't directly observe the phenomena, making it useless for block chains.

I read the two articles you linked to, and I suspect they're using "block chain" as a buzz word.  There's no way to do fully decentralized mining without giving control of the block chain to the people with the most efficient hashing hardware.

Their plan is probably to install a key pair on each device, sign each device's public key with the IBM master key, and then tell each device to accept messages from other devices as long as those messages have been signed with a key that was also signed by the IBM master key.

For example, my IBM car GPS will send traffic updates to other nearby IBM car GPSes.  Those GPSes will count my update as one authenticated vote.  If other nearby IBM car GPSes send the same message, eventually the message will have enough votes to cause all nearby IBM GPSes to choose alternative routes.  This is nominally "decentralized" and it may work until some IBM sysadmin signs 10,000 public keys for himself in order to get everyone off the highway so he can get somewhere quicker.


Wasabi CoinJoin Produces Non-Existent Coins/Transactions

There was a bug in the full node software we were using to broadcast transactions: Bitcoin Knots 0.19. Adam Ficsor (nopara73) upgraded the backend yesterday with Bitcoin Knots 0.20, which has already fixed the bug. However things will take a few days to fully resolve (probably 99% of issues have already resolved though) as the backend's mempool have to get in sync with the mempools of other nodes on the network.
About the bug
It turns out when you broadcast transactions to Knots .19 through RPC, it allowed double spending (without RBF.)
So, if it's fixed why does it take a few days to fully resolve?
Consider the following event:
Yesterday, after Adam upgraded the backend with the proper full node he participated in the first coinjoin. It happened and even his own personal Bitcoin full node accepted it. But when he looked at it in various block explorers it turned out they were not aware of it. What's going on here?
He traced back that one of the input has participated in another coinjoin that neither the backend, nor his local full node knew about. So everything worked properly based on what the Wasabi software knew about the network.
However this first coinjoin had to confirm in order for his local full node and for the backend's full node to be aware of it and realize it's the tx that actually happened. But why weren't the full nodes aware of it in the first place?
His local full node was not turned on at the time when that first coinjoin happened. This is how Bitcoin Core works, when it's restarted it doesn't start asking for full mempools, but it rather works with what it has.
The backend's full node did know about the first coinjoin tx, but because of the double spend bug, it threw that out. However with the correct full node version the correct mempool did still not instantly came back, but right now it's working correctly with the wrong mempool and in a few days as transactions are confirming everything will be back to normal, if not already.
If you are still experiencing this issue 3 days after my post, try to turn Wasabi off, then turn it on again.


Is there any way to find out latest bitcoin transaction of a particular address in bit-cli, without knowing the txid?

Bitcoind doesn't index by address, but you can scan the uxto set for outpoints which are spent to the address of interest:

See scanutxoset in the documentation:
https://bitcoincore.org/en/doc/0.17.0/rpc/blockchain/scantxoutset/
However, it is not clear to how it will be supported in the future: https://bitcoincore.org/en/meetings/2018/05/24/
Also note, that the utxo set may not return any result for your address, if the last transaction output associated with that address has been spent (not member of the uxto set anymore).

Alternatively, Libbitcoin-server indexes all transactions by address per default:

See the CLI command bx fetch-history <address>: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-history
Which makes fetch_history server request: https://github.com/libbitcoin/libbitcoin-server/wiki/Query-Service#blockchainfetch_history3
Above commands/requests will return ALL transactions in order of confirmation height related to any standard address and indicate whether the outpoint was spent or not.


Error when sending transaction: "Signature is found in scriptCode"

What you're spending is a P2SH output. To spend those, the last element of the ScriptSig must be the script (encoded with a push opcode, not the script itself) that produces that P2SH address when hashed.

See BIP16, especially rule #1.

  Validation fails if there are any operations other than "push data" operations in the scriptSig


Presumably, there's a limited number of these (even if it's a very very large number).

Yes, this is true.

  What's stopping someone from taking over all the bitcoin addresses?

Nothing. You can even guess someones private key and steal all their savings.

What you underestimate is how big a number can be. Every digit you add to your number multiplies number of tries you have to perform by 10. Computers might seem fast but they live in same realm, same rules apply to them. Very quickly you run into such big numbers that even biggest computing efforts on this planet can't keep up. Then you go further and when you have number you feel secure with, you stop.

This might seem stupid, because someone might get lucky and gain access to your "number". Yet we don't think twice about very simple passwords we use every day, for all our savings. Even if you have VERY complex password, it is likely nowhere near how big that number is. So we should perhaps start from improving our password practices a bit...

Simply put, this number is so unlikely to be guessed that it's too small for us to understand, much like understanding how many transistors processors have.

  is it something that's possible in a future 'quantum computer' type era?

Quantum computer isn't actually faster than normal computer. It's just that it can solve some problems faster. And when we get quantum computers, bitcoin will be broken because it doesn't use cryptography that can stand quantum computing. Those numbers (or rather structure they compose) will be easily reversible from publicly known information. So quantum computer will break bitcoin, but we don't even know if true quantum computer is possible (and no, we don't have quantum computer, it's just a easily-catched topic by media when somebody says so).


How is BID and ASK Calculated for crypto currencies?

Generally, the ask price displayed by the exchanges is the sell order at the lowest price. Ask is another way of saying sell. So Ask order = Sell order.

The same for bid orders. The bid price is the buy order at the highest price.

Speaking for the result of the below API call:

http://pubapi.cryptsy.com/api.php?method=orderdatav2

The order with lowest price among the "sellorders" is the Ask.

The order with the highest price among the "buyorders" is the Bid.

This is true for any trading pair.

There seems to be pairs where "buyorders" is null. That is either an error on their part or there are no bids for those pairs.


relationship between inputs in single transaction

Why address '367f4YW...' pay to itself?

While reusing addresses is not recommended for various reasons (privacy, security, etc), there is nothing stopping someone from doing so. If you'd like to send the change of a transaction to the same address you used an input from, you can do so.

  is it available to guess a relationship between '367f4YW...' and '15ozxv...'?

In many cases, if there are multiple inputs, you could assume that they are all controlled by the same wallet.

However, that is not always true. For example, P2EP transactions are looking to break this assumption, so that it is harder to guess at the nature of each blockchain transaction (ownership of inputs, outputs, etc).

For bitcoin to work best, fungibility is important. Making transaction inputs/outputs harder to decode is an important part of maintaining fungibility!


Bitcoin Core is moving to an edge router role

No. Edge routers are devices (Bitcoin nodes), not services.

Edge router is a term used in networking context: routers that are on the edge (boundary/border) of a larger network. For example a company network that connects to the internet. It often also serves as a firewall to protect that internal network from outside access.

In a similar fashion a Bitcoin core node can function as a firewall of sorts. Outside nodes can only directly communicate to that edge node but not to any other Bitcoin related software inside of the network behind it. Such an edge node would typically not contain a wallet itself, so there is no money directly at stake in case of an attack.

Other nodes on the internal network might contain for example a wallet or they may be running custom software that might contain vulnerabilities or consensus critical bugs that could be exploited if directly accessible to outside attackers.


How would I explain SegWit to a non-technical friend?

The name itself is a good hint as to what it actually does.

What we have today is a "witness" (i.e signature scripts) included in every Bitcoin transaction in non-segwit compliant transactions. This allows every full node within the Bitcoin network to verify the integrity of any transactions.

By removing the signatures in a Bitcoin transaction, you lose the ability to verify the integrity of the transaction. But in reality, not everyone needs to be able to independently verify the integrity of a transaction.

Thus, by segregating the signature from a transaction, we have a smaller transaction that describes the inputs and outputs exactly as it is. But if you want to know for sure that these are verified inputs, you'll look up the Segregated Witness set to find the corresponding scripts to validate the SegWit Transaction.


The idea of "bitcoin days destroyed" came about because it was realised that total transaction volume per day might be an inappropriate measure of the level of economic activity in Bitcoin.  After all, someone could be sending the same money back and forth between their own addresses repeatedly.  If you sent the same 50 btc back and forth 20 times, it would look like 1000 btc worth of activity, while in fact it represents almost nothing in terms of real transaction volume.

With "bitcoin days destroyed", the idea is instead to give more weight to coins which haven't been spent in a while.  To do this, you multiply the amount of each transaction by the number of days since those coins were last spent.  So, 1 bitcoin that hasn't been spent in 100 days (1 bitcoin * 100 days) counts as much as 100 bitcoins that were just spent yesterday (100 bitcoins * 1 day).  Because you can think of these "bitcoin days" as building up over time until a transaction actually occurs, the actual measure is called "bitcoin days destroyed".  This is believed to give a better indication of how much real economic activity is occurring on the bitcoin network.

So how well does it work?  Well, it's still not perfect, because the other day I moved some coins out of a wallet they've been in for several months without spending them or giving them away.  And some genuine businesses have very rapid turnover in bitcoins, so they're not being measured well by this method.  But it does do a good job of filtering out the "noise" of bitcoins that are just "bouncing around" without really going anywhere.  The graph of overall bitcoin days destroyed is believed to show that the genuine level of activity in the Bitcoin economy is continually increasing--it's not just one person experimenting by rapidly sending the same coins back and forth, flooding the network with meaningless chatter.  Looks pretty good, hey?

Image from the Bitcoin wiki.  The above graph is in percentage of bitcoin days destroyed and a little out of date--for a regularly updated version in bitcoin days destroyed check out Bitcoin Days Destroyed - Active Chart instead!


Bitcoin Wallet for Android/Windows with Full Control of BTC (keys)

There are a lot of wallets for Android & Windows in which you are on control your private keys. Here you can find a list recommended by Bitcoin Core.

Personally, I recommend Mycelium because is very complete.


How is a node selected to run Smart Contract in Ethereum

A node that runs a smart contract will be paid with GAS.

This is incorrect. The miner who mines the block containing the transaction interacting with a contract is the one who is paid with ETH, which is gas consumed * gas price.

  How is this node selected?

Through the mining process.

  Or multiple nodes are running the same smart contract just to make sure somehow?

Even after the block is mined, every node on the network that receives it will independently validate the contract execution. If the miner lies about the outcome of the execution, the block will be deemed invalid.


So after some investigations I realized that ZMQ support is not present on the latest tag on the repo (this line was in charge of giving me the latest tag).

So I think that my problem is by now resolved by using master as building branch.

Thanks at all,
Dario.


What is the algorithm of block selection using Target Difficulty?

Yes.  The test is that in order to be a valid proof of work, the hash found must be numerically less than or equal to the target.  That is certainly true of the hash found by Miner A in your example.


Is the Bitcoin network slowly closing down?

It could be that this host specifically is getting less connections, although that might not be the case.

There has been a similar drop in hashing power and stock price. The most likely cause of this is the lack of press-attention and a low amount of things you can do with Bitcoins. Another possible explanation is the increased usage of online-wallets reducing the need for locally running clients and therefore the total number of hosts connected.

Overall, no need to worry about the Bitcoin network closing down. In fact it seems to be about to grow faster again.

Some backing for my claims is here:
http://bitcoin.sipa.be/

Although it's hard to say anything from these charts


Up to 4 Different Points within ECDSA/Public Key Recovery technique

Negating an elliptic curve point means negating its Y coordinate (modulo the field size p), so -(x,y) = (x,-y). This implies that if you have a point R for which R.x mod n = k (where n is the curve order), then the same will be true for -R.

Furthermore, and with negligable probability, it is possible that both R.x and R.x + n are valid X coordinates (only when R.x < p-n). In that case, there are 4 possible points ((r, y1), (r,-y1),(r+n,y2),(r+n,-y2)).


How can someone lose funds in Lightning Network?

The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your funds are safe (technically you need to also keep some state information to sweep the outputs of those transactions). Apparently it is harder to keep several presigned transactions with a little state in comparison to just a private key.


chain.com Bitcoin API: Does not provide “making wallet” feature?

It looks like they don't support wallet features, only querying the blockchain for addresses, balances and transactions.  From the docs:

Get Bitcoin Address
GET /addresses/{address}
Returns basic balance details for one or more Bitcoin addresses.


Exchange Transaction versus Blockchain Verification

If you send 0.1 bitcoin to an exchange, you would see it credited to your account, but that doesn't mean that it is in a wallet solely dedicated to your account. Instead, that 0.1 bitcoin is sent to a wallet which aggregates all transactions to the exchange.

When you withdraw the bitcoin, a transaction is published from the aggregating wallet to your supplied bitcoin address.

All internal movements are just crediting and bookkeeping to the internal systems of the exchange. This is the reason why it is generally not advised to keep bitcoin an an exchange for very long. If the company goes bankrupt or is hacked, you won't be able to retrieve your funds, because you don't have control over the wallet.


How to Avoid Wallets Compromised by Android Vulnerability

As this bug has been fixed the best idea is to archive those addresses which have been generated before the update (not all wallet applications support this feature). The other is to completely remove the wallet and replace with a new updated version.

As far as im aware no wallet supports deletion of addresses (for obvious reasons).

As for creating transactions, on specific wallets some have more detailed sending abilities than others, its all about a balance of userfriendly vs features. If you look at blockchain.info wallet it has advanced features allowing specific send from and change addresses to be set, most mobile apps will probabaly lack such sophistcation due to being made for mobile.


How can you tell if you're at the end of an incomplete blk*.dat file?

It is perfectly possible that *.blk files contains gaps of zeroes, or even partially written blocks. In modern versions (since 0.10 or so) this won't happen during normal operations, but it can't be prevented in case of abnormal shutdown (crash, out of disk space, ...).

If you want to be sure, you need to scan the entire file for potential blocks (they'll always start with a magic + length descriptor, so you can quickly skip many things). That, or use the getblock RPC instead, which uses Bitcoin Core's prebuilt index.


Help locating bottleneck on new mining rig

Did you check the CPU usage? You can use TOP on Ubuntu (sudo apt-get install top, if it's not default). If it's not capping out at 100% it's either the chipset or CPU bandwidth giving up. You can also check you regular memory, although I'm quite sure that isn't used in GPU mining.

Some things you can easily strike off are network and disk. Disk isn't used at all and network shouldn't cap out even on dialup.

If it is in fact chipset or CPU bandwidth you have two options:
1. Overclock. Focusing on FSB clock should improve everything. I'm quite sure you can't get a 300% increase though.
2. Build a different system. I daren't advice about this though.


Recovery after losing wallet.dat and formatting hard disk

Your money is lost without at least one of

a backup of important data from the hard disk before it was formatted
a backup of the wallet.dat file
a note of the private key

There is no way to recover the private key from other information. If there was, Bitcoin would be completely unsafe and unusable.


the only iPhone wallet app offers NO WAY to include a transaction fee?

I can't elaborate much on your answer but can provide reasons as to why this market seems so bare.  Apple has shut down other providers of BitCoin wallets for "legal reasons" -- all due to the legal ambiguity of BTC transactions.

Your best bet is to look into mobile-optimized websites that offer BTC transactions.  I'm unfortunately not too knowledgable on the topic - but at first glance, you might want to check out https://walletbit.com/, https://bips.me/ or something similar.  Happy hunting!


Could a Proof of Burn function be implemented into Bitcoin Core to help prove loss of private keys?

There's already a way to burn bitcoins. You simply assign the bitcoins to an OP_RETURN. No need for the complex machinery.


How do I get credentials on the bitcoin network?

I have to fill in these values in the config:
  bitcoind.rpcuser=bitcoind_rpc_user_string
  bitcoind.rpcpass=bitcoind_rpc_password_string

These are user defined, and used to authenticate and communicate with your full node. There is no authentication to the network, anyone is free to join.

You’ll want to define a username and password in your bitcoind bitcoin.conf file, and then input them here so that lnd can connect to your node.

  Also can someone explain these settings to me:
  bitcoind.zmqpubrawblock=tcp://127.0.0.1:18501
  bitcoind.zmqpubrawtx=tcp://127.0.0.1:18502
  Is 127.0.0.1 ok to leave for these values?

ZMQ allows lnd and bitcoind to exchange info through a socket connection (getting new info about blocks and transactions). If the nodes (lnd, bitcoind) are on the same machine you can leave the address as the localhost (127.0.0.1).


Are private keys published to the blockchain after spending coins from a wallet?

The answer is no. Your private key is never transmitted to the network for any reason.  You may wonder how the network can validate that a transaction is "yours".

This is possible because Bitcoin uses Public Key Cryptography (also know as asymetric cryptopgraphy).

Your addresses consist of a pair of keys which are mathematically linked.  It is easy to determine the public key from the private key but impossible to determine the private key from the public key.  It is more accurate to say it is computationally infeasible to determine the private key from the public key unless there is some cryptographic flaw.

Your public key is included in the transaction (along with destination and amount).  The entire transaction is then signed with your private key.  The signature is unique based on your private key and the contents of the transaction.  Someone can't re-use a signature because it is only valid for a unique transaction.

When the network detects a transaction it will verify it by comparing the signature and public key to the transaction.  While an attacker knows the public key he would need to know the private key to generate a valid signature.

Forgery/counterfiting is prevented because it is computationally infeasible (millions of years) to determine the correct signature without the private key.  It is not possible for an attacker to change part of the transaction (like changing amount in fiat check fraud) as that would require  different signature to be valid. The network can safely assume that if the signature is valid it must have been signed by the owner (presuambly with owners consent) and thus the transaction is valid.

This is why you must keep your wallet.dat secure.  If someone gains access to your private keys they can sign transactions as you.  Once an attacker can sign any transaction as you the best transaction is to transfer of all funds into account they control.


when you are doing

BitcoinAddress address1 = **pubKey**.Derive([some client data]).PubKey.GetAddress(Network.Main);

You are getting the bitcoin address, but not the master public key. (ExtPubKey)
A HD pub key have more information than just the pubkey.

The correct code is

string wifStr = **pubkey**.Derive([some client data]).ToString(Network.Main)

Then you can reload it

ExtPubKey key = ExtPubKey.Parse(wifStr)

In fact, the string format of an ExtPubKey have the Network to which it belong, that's why you also have the type "BitcoinExtKey" which represent in object oriented form both : the ExtPubKey AND the Network. If you need it :

BitcoinExtPubKey wif = **pubkey**.GetWif(Network.Main)

Take a look at my book, there is other code samples around HD keys.

Concerning the best practices, there is no silver bullet right now. I created an API called RapidBase which permit you to create wallet and add addresses to monitor in this wallet. (You can find it on github)

You can try it if you want, but it is very unstable for now (API wise), so expect things to change in the future. If you are using blockr, I think your best bet is to request each addresses as you are doing.

If you are using bitcoinq RPC, you can add address, but it takes time since bitcoin core will rescan the blockchain for fetching the relevant transactions each time.

I might be wrong, but for now there is no easy to use solution, exception rapidbase I developed, that is not very stable for now.


If it says the wallet is encrypted, then it's encrypted. I can't imagine any way the wallet could be encrypted other than that you encrypted it. You can try as many passwords as quickly as you want, so maybe you'll remember it.


Constructing a P2WSH address from the BIP173 spec

First of all, what are you trying to do? Why do you need a P2WSH address?

A P2WSH address (and P2SH addresses earlier) send coins to a script, which requires satisfying that script to decode. A script of the form <key> CHECKSIG is wasteful - you should be using P2WPKH instead. In general, you use P2WSH when you have more complex spending requirements than a single key. This most often happens when you need multisig (multiple devices or people need to sign off on a spend).

Now, all of this is outside of the scope of BIP173, which only specifies how to encode segwit outputs into human-readable strings and back.

A segwit output is an output whose scriptPubKey starts with OP_0, OP_1, ..., OP_16, and is followed by a push of 2 to 40 bytes. That's it, and BIP173 can encode any of those.

Now, since the activation of BIP141 in Bitcoin, a small subset of segwit outputs have been given a meaning:

OP_0 + 20-byte push of RIPEMD160(SHA256(pubkey)) is called a P2WPKH for that public key.
OP_0 + 32-byte push of SHA256(script) is called P2WSH for that script.

All other kinds of segwit outputs are meaningless right now (non-standard and spendable by anyone), but that could change in the future. However, all of them can be encoded in Bech32 using BIP173. It doesn't care what the context or meaning is; it just encodes the version number (the OP_n opcode at the start) and the data bytes (what is being pushed afterwards).

Perhaps your confusion comes from the fact that the BIP173 test vectors use "key + OP_CHECKSIG" in its examples. That was just a simple way of constructing examples that are reproducible. They're not representative for how to actually use it.


Effects of mining pools paying for stale shares/work

Stale shares have no chance of being a valid block credited to the pool, thus submitting one contributes nothing to the pool. The default behavior, then, should be not to pay for invalid shares. (A comparison with matching the difficulty target is illustrative. A miner has no influence on how many of his shares match the target, and hence it is fair to be rewarded for failed shares; however, he does have an influence on how many of his shares are stale, as these can be a result of latency on his end.)

If a pool decides to pay for stale shares anyway, this must come at the expense of someone else (as the total average reward of a pool with a given number of non-stale shares is fixed). The identity of "someone else" depends on the reward method of the pool.

Methods like PPLNS do not absorb any variance, and the operator can never lose or gain any money (beyond a fixed fee); 100% of any block reward is distributed among miners. If stale shares are counted for the purpose of dispersing rewards, it means the non-stale shares are rewarded less on average. If all miners have the same stale rate, this has no effect whatsoever on their average reward; there's the same total reward to go around, so what they gain in rewards for stale shares they lose in rewards for non-stale shares. If different miners have different stale rates, this benefits miners with many stales at the expense of miners with few, removing any incentive for the miners to minimize their stale rate.

Some methods absorb variance, the most extreme case being PPS; any statistical deviations manifest as a profit or loss for the operator. If the pool offers payment for stale shares, it comes out of the pocket of the operator. If the stale rate is assumed fixed, this amounts to an effective fee slightly below the nominal fee (e.g. if the nominal fee is 3% but the pool pays for 0.5% of stales, the effective fee is ~2.5%). If the stale rate is not fixed, then the pool becomes more attractive for high-stale miners, and relieves them of the need to worry about their stale rate. This is detrimental to economic efficiency, but can be easier psychologically. To maintain a profitable business, the operator will need to carefully balance his nominal fee with the stale rate of his target audience.


Redirected from a real exchange site to a fraudulent site?

If it's a fraud, how could they have sent a fraudulent link through a real binance email address?

It has long been trivial to forge the "from" address in Internet e-mail. You could learn how to do it in about thirty seconds.
See https://en.wikipedia.org/wiki/Email_spoofing

The core email protocols do not have any mechanism for authentication, making it common for spam and phishing emails to use such spoofing to mislead or even prank the recipient about the origin of the message.

The link above goes on to describe countermeasures - but note these are not universally applied.


In the paper The Art, Science and Engineering of Fuzzing the authors define fuzzing as “a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed”.
Fuzz testing is not a new concept. It was introduced in the early 1990s but at the present time its potential for finding bugs has not been fully explored in the Bitcoin Core codebase.
Of course fuzzing is a technique not only used by those seeking to prevent bugs in a software project (defenders) but also those seeking to exploit a bug (attackers). There is a danger that if projects like Bitcoin Core fall behind the state of the art in defense techniques that attackers could take advantage.
Matt Corallo discussed fuzz testing at London Bitcoin Devs in February 2019.

Fuzz testing is a general testing approach of black boxing a test case that takes as input some random set of bytes, running a program on it and trying to make it crash. This is primarily used for decoders, things like that. They have proven to be very, very, very effective at taking an image decompression library or something that processes untrusted data off a network and making it crash, finding vulnerabilities in it, finding stack overflow, buffer overflow kind of vulnerabilities. They are not just completely dumb, like shove in random bytes. They actually instrument the binary. Usually what they do is they instrument the binary, and you can do this in hardware or in software, and detect when a given input has found new paths in the program. So you map out all the if statements and all the branches in the program and if it finds an input that hits a new branch then it considers that input interesting and it will mutate that input a little bit more than other inputs.

Matt Corallo added at Advancing Bitcoin in February 2019:

Fuzzing has been incredibly useful across the software world but mostly for finding vulnerabilities in things like image decompressors, image decoders, message deserializers, that sort of thing. And what it does is you write a program that takes as input some arbitrary string of bytes and you do something with those bytes and the fuzzer tries to make you crash. So if you have some image decoder or decompressor often times it will find a bug where you used too much memory, you have an out of memory condition and you have a DoS vulnerability there. Or maybe it will find a bug where you have some buffer overflow, something like that. Or whatever depending on the language you’re writing in. Fuzzers have been amazing. You can go look up all of the various CVEs and vulnerabilities they’ve found. We’ve been playing a lot with them in rust-lightning and we have the standard ones of just make sure all of our message deserializers don’t crash or don’t use infinite memory. But we also have some allow nodes to do completely arbitrary things. So we have one fuzz target that runs a full node and can receive bytes on the wire. This allows you to literally do anything that another node could do to you possibly in a fuzzing environment where the fuzzer is trying to creatively crash your program and comes up with different inputs that might exercise different code paths


Person did not receive the amount of bitcoin I sent

Here is the transaction you sent, displayed by a block explorer:

It can be seen that the transaction created two outputs:

1AHpgNCRHg41wmX4SWvsA8eq7wcN6gPKMi 0.59573100 BTC

1LSpWLjsQS3Z5j49gFXNy8YYHz8sMjUMr4 0.00046671 BTC

I assume that the 1AHpg.. address is what you paid your friend, and the other address is your change. But in any case, neither of the outputs is ~$400 in value currently, so your friend is mistaken/lying to you about what they received (or they are using some extremely broken wallet software).


Do Berkley DB versions need to be the same?

To be safe, you should use BDB 4.8 as that is the version that is used in releases. However using --with-incompatible-bdb should still produce wallet.dat files that can be used with the officially built clients.

You may find that people say that the BDB database files are incompatible from version to version. Furthermore Oracle, in their own documentation, say that there are no guarantees that database or environment files are compatible from version to version, even from minor version to minor version. But from researching and testing this out myself, this is not true in practice.

BDB rarely changes the database file format. Rather what does tend to change are the database transaction logs. These log files are used to ensure Durability (the D in ACID). Oracle has changed the log file format in minor versions so they are not backwards compatible (they are forwards compatible, so you can always move to a newer version of BDB). When you use --with-incompatible-bdb, you will probably be using a newer version of BDB that has incompatible transaction logs. So this would be a problem.

But Bitcoin Core actually mostly takes care of that problem for you. The transaction logs are removed if the wallet is able to be closed cleanly. So if nothing crashes and the wallet file is closed normally, you will be able to use a version of Bitcoin Core compiled with a different BDB, and then have the official release be able to use the same datadir and open the same wallet files.

In the event that Core crashes or the wallet files are otherwise uncleanly closed (e.g. power loss), then you should use a build of Bitcoin Core using the same BDB version that you had been using prior to the unclean shutdown. This will ensure that the transaction log can be read correctly and any information replayed and written to the wallet.dat file.

So what versions are compatible? From my own testing, I have found the following versions to work with no modification to Core necessary (Note these versions are what Oracle has available for download, versions with the same major and minor number of different patch number should still work):

4.8.30 (Note this is the version that Core ships with)
5.0.32
5.1.29
5.2.42
5.3.29

6.0 and above are not backwards compatible as they database file format has changed for these versions. You would be able to use 6.0+ but any wallet.dat files created by them cannot be used in the official binaries. However existing wallets created with the official binaries or one of the above versions of BDB could be used with a build that uses 6.0+ and be subsequently used again in the builds with older BDB versions. I.e. you could go from 4.8 to 6.0 and back to 4.8 with the same wallet.dat file.

4.7.25 also works but requires you to modify configure.ac to be able to build with a version less than 4.8.

4.6.21 requires modifying some code as API calls changed, but the database format still works. 4.5.x and below have significantly more API differences so I wasn't able to test them.


What is the story behind US senators wanting to "crack down on Bitcoin" in mid-2011?

There were some reports on Silk Road at the time, and they wanted action against Silk Road.


What is the length of largest known reorganization in bitcoin?

There have been only two large re-orgs in Bitcoin's history. The first is the value overflow incident in August 2010 that caused a re-org of 53 blocks and the March 12, 2013 fork that caused a re-org of 24 blocks.

Value Overflow Bug
On August 15 2010, it was discovered that block 74,638 contained a transaction that created 184.4 billion bitcoins for three different addresses. Two addresses received 92.2 billion bitcoins each. Yes you read that right. 184.4 billion Bitcoins!!! This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed.
Integer overflow is the digital equivalent of a mechanical odometer wrapping around to zero after the car drives 999,999km. The overflow caused the software to think that the transaction contained only a small amount of BTC while in reality the outputs together had thousands of times more than the 21 million that should ever exist.
Satoshi published a new version of the client within five hours of the discovery. This release contained a soft forking change to the consensus rules that rejected output value overflow transactions (as well as any transaction that paid more than 21 million bitcoins in an output for any reason).
Although many unpatched nodes continued to build on the "bad" blockchain, the "good" blockchain overtook it at a block height of 74,691 at which point all nodes accepted the "good" blockchain as the authoritative source of Bitcoin transaction history.

March 2013 Chain Fork
The v0.8 release of Bitcoin Core switched the database that it used to store blocks and transactions from BerkeleyDB to LevelDB as part of an effort to reduce blockchain synchronization time. A bitcoin miner running v0.8 created a "large" block (at height 225,430) that was incompatible with earlier versions of Bitcoin leading to the Bitcoin blockchain split into two, with one half of the network adding blocks to one version of the chain, and the other half adding to the other.
In order to make an update to the database, the database process must make a “lock” on the part of the database which stores that particular item of information, a mechanism implemented to prevent two changes from occurring simultaneously and accidentally corrupting the database. In a b-tree, the data structure used by BerkeleyDB to store objects, two locks are required per update. However, BerkeleyDB requires its users to set a limit to the number of locks that can be made at the same time. If the values are too small requests for locks in an application will fail. If the values are too large, the locking subsystem will consume more resources than is necessary.
In the case of Bitcoin, this limit was 10,000. What happened in block 225,430 was that a single block simultaneously affected the status of over 5,000 transactions, requiring more than 10,000 locks on the b-tree to be made at the same time. As a result, BDB failed, and so the older (v0.7 and earlier versions) could not read the block. In the case of v0.8, LevelDB has no such restrictions, so it could accept such blocks just fine.
It was finally resolved by miners downgrading their Bitcoin Core to v0.7. This placed majority hashpower on the chain without the "larger" block, thus eventually causing the v0.8 nodes to reorganise to the v0.7 chain.


To transact in Bitcoin you will need to broadcast the transaction to the Bitcoin network.  At this time an internet connection on your phone is going to be a requirement, a wifi hotspot at the cafe is all you need.

In theory there are other ways to get the transaction to the network for example sending the transaction directly from your phone to the point of sale system using NFC or Bluetooth. Search bitcoin over NFC or Bluetooth and you can read about these.

Sending the transaction over SMS is also a possibility in the future

Edit: As pointed out Bluetooth and NFC support is already built into some wallets. See Bitcoin Wallet or Airbitz for example.


Altcoins with plaintext transaction messaging

check out: https://nxtwiki.org/wiki/Arbitrary_Messages

  The NXT Messaging system allows you to send and receive data on the
  NXT Blockchain, thus allowing any Nxt account holder to communicate
  directly with all other account holders.

  Messages can be attached to any Nxt transaction, making bookkeeping
  easy, as you can tag all your transactions with a description. Project
  developers can use the Messaging system to embed machine-readable data
  within an Nxt transaction. This allows automated functions by reading
  the data sent to you on the blockchain.

  Messaging is securely encrypted by default, but text or data can also
  be sent unencrypted.


How much time does it take to transfer BTC into btc-e hosted wallet?

BTC-e waits for three confirmations, and then takes a minute or two more.

In my experience, it took 12 minutes. YMMV.

This is documented on the BTC-e website. Login, then click on 'finances', then click on the 'deposit' button on the BTC row.

The minimum incoming transfer is 0.0001BTC.  I don't know what happens if you transfer a smaller amount.


PHP: is there a way to convert a private ECDSA key to its corresponding public key?

Yeah, you do "need some code which multiplies some coordinates on the elliptic curve" :). If you don't have extensive cryptography experience I would recommend you use library rather than trying to implement details yourself.

Googling I've found Bitcoin-lib-php. Looking at  the code it seems it seems this function does exactly what you are looking for.


how to activate BIP148 in bcoin configuration

You can Update their node software to a BIP148-enforcing version; or
Run a BIP148 border node to filter out invalid blocks, and update their existing mining software to produce blocks with version 1 bit enabled, to vote for Segwit activation.
Signed binaries can be downloaded at BIP148

First, install all necessary dependencies which are mentioned in the official Bitcoin build instructions details UASF


There is no rpcuser.py script anymore, it is now named rpcauth.py (the ppa may not be up to date). This file can be found in the Bitcoin Core source code repository: https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py


What are some ways that the powerful elite can thwart cryptocurrencies?

Here are a few ways Bitcoin can be affected by the decisions of a wealthy investor:

Value manipulation: A wealthy investor can sell coins or purchase coins in such a rapid pace that the market sinks or rises to an unrecoverable level.  In real exchanges, the SEC protects investors from these hostile trades.  There is no SEC protection with Bitcoin.  Update: there apparently is now SEC prosecution for Bitcoin matters
Negative press / word of mouth: Part of the success of Bitcoin rests on it being freely exchanged for goods and services.  If Bitcoin becomes overly associated with the darker parts of the internet, then some businesses will become risk adverse and not want the additional scrutiny on their private ledgers (tax, audit, etc).  However if BTC is associated with "good" things then the inverse is likely to happen.
Protocol hacks: If an elite person discovered, or a team is funded to discover protocol issues with the Bitcoin network, and a flaw is found, that will undermine investor confidence in the system. (e.g. Malleable Transactions)
Laws on M1, M2, M3 transfers: Bitcoin is unique in that it can be purchased with USD and sold back to Bitcoin and back to USD.  This feature is different than other items such as a calling card, gift card, Amazon coins don't have this two way feature.  The less isolated a currency is, then the more likely it will have regulations apply to it.  Regulations are supposed to protect the merchant and consumer, and these regulations will likely be placed on all exchanges.  It has already started with the recent FinCEN announcement.
Manipulate or create a Internet outage, a massive sustained power outage, like the 2003 Northeast blackout, covering an area with a heavy miner concentration.
An over dependence on a single exchange, with no auditing or external oversight, could manipulate the currency value with a double set of books.

Any player in the Bitcoin system who also needs to use the value of Bitcoin in a local currency will likely have most regulations placed where the BTC ↔ currency conversion is done.  Identification "checkpoints" and other analysis will eventually be done on trades to identify the good guys from the bad.   Depending on which side you're on, this could be thwarting one's intentions.


This is a P2SH script (pay to script hash), defined in BIP 16.
The scriptPubKey itself is very uninteresting: it takes an element from the scriptSig, hashes it with OP_HASH160, and then compares it with 0b49fe...f1. In other words, ostensibly the only thing needed in order to spend is knowing some piece of data whose hash is 0b49fe....f1.
Now, BIP 16 changed this. If a scriptPubKey has exactly the form OP_HASH160 + 20 byte hash + OP_EQUAL, then the special P2SH validation rules trigger:

All operations in the scriptSig must be pushes.
The final push in the scriptSig (the one whose hash we know is 0b49fe...f1) is taken to again be a Script (called the redeemScript).
That Script is executed, with as inputs all but the final push in the scriptSig.

So, semantically, the whole operation is equivalent to just using the redeemScript as scriptPubKey, but without needing to reveal this to the sender. Instead, the sender can just be given a short P2SH (3...) address that encodes the hash of the redeemScript, and the real one is only revealed at spending time.
In your example, the redeemScript appears to encode a 2-of-3 multisig policy: OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG, and the additional stack items in the scriptSig are OP_0 (a workaround for a bug that OP_CHECKMULTISIG pops off one item too many from the stack) plus 2 signatures.


How to Install Copay desktop wallet in Ubuntu?

These are not instructions to install it. These instructions are for building Copay on your system.

Here are the instructions for end-users (non-developers):

  1) Download the latest binary

You should visit its Copay releases page on GitHub and choose the ZIP file for Linux.

After you download it, unzip it and make sure you moved its folder to somewhere you won't forget.

  2) Run it

Open the Linux Terminal (Press Ctrl + Alt + T to open Terminal if you're on Linux Mint or Ubuntu)

Open Copay's folder (which you just unzipped and moved).

There should be ~ 20 files and folders in that folder.

Find the file named "Copay" (without quotes and its icon may look like a document), drag that file onto Terminal and press Enter.

Now its GUI should open. Please note that you have to do Step 2 everytime you want to run it.


Witcoin was written and run by mizerydearia. At some point he became unable to run the site, but he was/is unwilling to give the witcoin database or wallet to anyone else. (Someone else owns the domain name.) Mizerydearia was very intelligent, honest, and active, but it seems likely that he's developed some sort of mental illness (as you'll see if you read his forum posts). It's very sad. Hopefully he'll someday recover enough to run witcoin again or at least refund the BTC.


Decentralized product inventory (instead of simple orderbook)

I think Ethereum is ideal for this.  As you say, it's not ready for prime time yet. But I think it offers the most flexible toolkit for managing orders in a truly decentralized way. You can create and manage arbitrary database structures that are secured on the blockchain.

I wrote a toy digital artwork market using Ethereum -

http://robmyers.org/2014/07/24/ethereum-art-market/


Open a coinbase account -> get a 'receiving' address from your coinbase account -> send a transaction from Copay to coinbase. Right now the network is congested due to high traffic, so it may be worth waiting to make this transaction if you'd like to save money on fees. Getting a quick confirmation right now will be expensive.


Why block height is required in coinbase?

In his comment @amaclin pointed to BIP-30 which provides motivation for BIP-34.

I still don't understand what is "to better reason about plausible difficulty for not-yet-connected blocks" but it seems that the sole point of BIP-34 is to prevent intentional creation of duplicate coinbase transactions.

According BIP-30 they can be used in several attacks:

  Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.

This answer by Pieter Wuille explains blockchain forking in more detail.

Contrary to the explanation in BIP-34 pull request, adding block height to coinbase does not guarantee that every subsequent transaction hash is unique. It only makes harder to create transactions with same hash intentionally. There is still possibility that some unrelated transactions will clash.


Is there a Bitcoin exchange which has bank accounts in South Korea?

CryptoXChange.com will let you withdraw KRW directly to your bank account in South Korea. They just opened about a week ago.


bitcoin address after transaction security questions

1.) Is it safe if I create a raw transaction on the offline computer so I can execute it on my online computer?

Yes, this method, called using cold wallets is very effective at keeping coins safe.

An address either never spends (the public key is not revealed) or it spends (the public key is revealed). Spending fewer times from an address won't make it less secure (unless you use very old or home-made signing code). And the security difference between non-spending and spending wallet is negligible. (Otherwise, there would be a price crash and chaos)

Every input has its own signature, not every output. So, by making all those payments at once, you'll save lots of $ in transaction fees.


Bitcoin Client API-RPC: Efficient way to list transactions from a list of addresses

The most efficient way to get a list of transactions from multiple addresses is to store every wallet transaction in a database locally, something like MySQL or MongoDB, and then run your queries on that database.

You can sync your local database with the Bitcoin wallet via RPC by periodically calling listsinceblock() and keeping track of the last block or by running the client with the optional -walletnotify parameter to run a script to notify your database of new transactions.

Be careful with -walletnotify however. It will be called twice for every transaction and if you have a lot of transactions, it can happen a lot. So make sure the command -walletnotify calls doesn't use a lot of CPU/RAM.


Will Bitcoin remember unperformed transactions?

First of all: there's no guarantee that it will be free after 15 days. Some miners used to have a policy that made spending old coins potentially free. But miners can change those policies and will likely go for highest fee first, as that earns them the most money. If the network is busy that means there will be hardly any free transactions going in.

Second: most nodes on the network keep transactions in the memory pool for a while. But again, the exactly policies can be different for every node. I think 3 days is a common setting. But when the network is busy, 0 fee transactions are more likely to be dropped from the mempool than paying transactions.

Third: once you've broadcast the transaction, theoretically anyone that ever saw that transaction could re-introduce it to the network at any time. Even weeks or months later. For example the receiver of such transaction might keep trying to get it through. So there's never really a guarantee to you that a transaction has "timed out". The only way to be sure is to make a new transaction spending the same coin to another address (and then include a fee).


In your example, there will be two chains of transactions as different transactions are spending the outputs of one transaction. Because there are two distinct transactions spending from those two outputs, there are now two transaction chains coming from one transaction. However this does not mean that the transaction chains won't converge or meet. Calling it a transaction chain or a tree isn't really accurate. It's actually a directed acyclic graph.


Transaction fee required by bitcoin-cli keeps increasing as I increase the fee

The problem with sendtoaddress is that the transaction size isn't known in advance.  It may be that by adding a fee, you are needing to include a new input in the transaction, but inputs are the largest and therefore the most expensive part of the transaction, so that makes it still more expensive.  That would be most likely if you have a lot of addresses with small amounts in them.

Also, settxfee sets the fee per KB, but from a quick review of the code, that message seems to be printing an absolute amount rather than a rate per KB.

You may want to adjust the settings described here:

https://bitcoin.org/en/release/v0.12.0#wallet-transaction-fees

For complete control, you can use createrawtransaction/fundrawtransaction, or use an external system (e.g., coinb.in) to create the transaction and just sign it using your core wallet.


You can run Hyperledger Caliper https://www.hyperledger.org/projects/caliper/ , a benchmarking tool that supports Hyperledger Fabric (IBM), Hyperledger Sawtooth, Ethereum, and other blockchains.

Click on "Get the Code" link in the link above, or go to https://github.com/hyperledger/caliper for source code. It's thousands of lines of code, including benchmark blockchain apps, so that's too much to post. The original link above has documentation and is the main Caliper project page.


Windows vs Linux for bitcoind (not mining)

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

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

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

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

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


try:

import pybitcointools

that fix my problem


Sidechains are supposed to make it possible for users to move bitcoins between different bitcoin-based blockchains with different rule sets. For example, in this way, new techniques for preserving the privacy of transactions or a smart contract system similar to ethereum's could be added to a bitcoin blockchain, without changing the bitcoin blockchain. They are as an architecture for building semi-decentralised products and services for Bitcoin that were simply impossible before. With sidechains, users won’t be affected at all by any new programming.

Drivechain is a two-way peg for interacting with the sidechain. The key difference between drivechains and regular sidechains is who ultimately submits the necessary information to transfer the bitcoins back and forth: the users or the miners.

The side chain idea allows the native cryptocurrency to compete and win out over other competitors, as they are faster confirmed.


Error trying to send payments with RPC sendmany

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

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

In paymentProcessor.js, change

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

to

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

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

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

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

And the error was:

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

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

In my case, (1) would look like:

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

And (2) would look like:

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


Quarkcoin's bitcoin-qt fork won't recognise unspent transaction

https://bitcointalk.org/index.php?topic=231309.0 worked for me, as it says:

Export your private key in base58 format (how to do this depends on the software used to make the unconfirmed transaction, but I'm sure it is straight-forward)
Create an empty wallet in bitcoin-qt (can be done with renaming your current wallet.dat to wallet.dat.bak and launching bitcoin-qt. Just be sure to keep wallet.dat.bak...)
Launch bitcoin-qt
Import the private key into bitcoin-qt (see this: https://en.bitcoin.it/wiki/How_to_import_private_keys_v7%2B)
Quit bitcoin-qt
Run
bitcoin-qt -rescan
Wait
Wait...
Now you have the full balance of the single key you imported (compare with blockexplorer. If not, stop here and post in this thread)
Create the transaction you wanted to do without forgetting the fee
Delete the new, nearly empty wallet.dat (just rename it if you're not sure about that part)
Rename wallet.dat.bak (thus your original wallet) to wallet.dat
Done


Easiest way to do this is to first load watch-only wallets of the multisig lockbox you hope to create. Say, you want 2-of-3 and you have 3 watch-only wallets.

Go to Lockboxes -> Create Lockbox -> and click the address book icon next to each public key #1. Highlight the wallet you want the public key to be from and select an address below that hasn't been used yet. Repeat for public key #2 and public key #3. Generally, you should be choosing from different watch-only wallets.

Click Save Lockbox and you now have a new multi-sig p2sh address!


When a transaction is split into two outputs, how does the network "know" you're the owner of the "change" address?

The bitcoin network does not know who owns which address. The concept of an address doesn't even exist at the protocol level - it's just an authentication layer on top of the scripting logic in transactions.

And of course your own client does - because it has the private key for change addresses it generated itself. That's all that matters. When spending a transaction output, the client will prove that it holds that private key by creating a digital signature that matches the address. That's all the network cares about.


The command you want to use is walletprocesspsbt. The only argument you need is the PSBT itself.


Can Bitcoin technology be leveraged to implement a decentralized trust system (i.e. a replacement to SSL)?

While it's certainly possible to implement a script to handle trust the way NameCoin handles DNS-like transactions there are a few possible "weak links" in such a system. First, since an individual can't usually be known the trust could only be tied to individual addresses, which would encourage the re-use of addresses and thus decrease the anonymity of the network as a whole since merchants would want to find ways to get around generating a new address for each transaction in order to maximize their trust rating. The only alternative is to implement a system of binding multiple addresses into one trusted "account" which would further compromise anonymity by making it known precisely who owns which addresses thereby tying at least one side of most Bitcoin transactions to a real person.

In short, it's possible but it kills the pseudonymous nature of the network and makes transactions far too traceable to real identities. It could be implemented, but given the private (and disruptive) nature of most Bitcoin proponents it's unlikely that it will be. An external "Web of Trust" type system carries adequate benefits without compromising Bitcoin itself and in fact, there has been a great deal of discussion on how to decentralize them.


Since November 17, 2011 no fee is charged.  Instead an optional donation of 0.5% is sent to the author of P2Pool to support future development.

If you don't want to donate to the author you can run P2Pool like this:

python2 run_p2pool.py --give-author 0.0 [USERNAME] [PASSWORD]

The 0.0 is a percentage of your earnings and can be set to whatever percentage you like.


your "Public Shared Function GetSignature" works fine! I have been racking my head for a couple of days writing my own but with no luck! Thanks for your snippet!

As far as your problem someone may have already answered it.

To troubleshoot further problems I recommend after you get an HTTP Error to continue your stream and GDAX will give you helpful information.

here is how I handle a web exception.

          Catch ex As WebException

        Dim output As New ClassWebRequestOutput
        output._ErrorMessage = ex.Message.ToString

        Dim exResponse As String
        output._Error = True

        exResponse = New StreamReader(ex.Response.GetResponseStream()).ReadToEnd
        output._Resopnse = exResponse

        Return output
        Exit Function

This continues the web connection with helpful hints.


Can the Large Bitcoin Collider project 'break' into offline hardware wallets like the Nano Ledger S?

If LBC is somehow able to guess anyone's private key, regardless of how the private key is normally stored and generated, then yes, they can just spend the coins. All you need is the private key, it does not matter how the key was obtained.

Of course this is impossible to do in practice with today's technology. The range of possible private keys is incredibly large, much larger than a human can imagine. If the private keys were generated with sufficient randomness (which Ledger Nano S's do as they have a True Random Number Generator), then the probability of generating a private key that is in use is so small that it is effectively zero.


What redeem script is used in bitcoin core wallet when generate the address?

You can use the getaddressinfo RPC command in the latest version of bitcoin core to get the hex encoded script for that address. But note that because you were able to get a private key, I assume this is a P2SH wrapped segwit address, which means the script is just an OP_0 opcode followed by the hash160 of the public key corresponding to that private key.


The only omni-specific thing in Omni/Tether txs is the OP RETURN, and a small dust output to the address you are sending the funds to. Both of these seem to check out in your tx (I'm assuming you're sending to 1KH34S5mAmgAzu3mJAqrS3wjP15qYKZQXx).

You should be able to just use the regular Bitcoind signing functionality (or whatever library you are using's wrapper of it). They don't require any special signatures.


How To Traverse Bitcoin Addresses in HD Wallet

Most (but not all) wallets will follow what is specified in BIPs 32, 44, and 49.

BIP 32 defines what derivation paths are and what they mean. It is the standard for deriving all of the keys in a HD wallet.

BIPs 44 and 49 specify derivation paths that wallets should use. BIP 44 defines a standard derivation path format: m / purpose' / coin_type' / account' / change / address_index. It also defines the purpose for non-segwit Bitcoin keys.

When a wallet is deriving the keys, the path for external keys, i.e. those keys which you get by clicking "New Receive Address" (or similar) is m/44'/0'/0'/0/i and i is just incremented for new keys.

For internal keys, i.e. keys for change addresses, the derivation path will set the change field to 1, so the path will be m/44'/0'/0'/1/i and i is incremented for each new change address that is needed.

Since that change field is essentially a boolean, there is no need to iterate through any indexes other than 0 and 1.

BIP 49 specifies the purpose for keys used for P2SH nested segwit addresses. It just sets the purpose field to be 49, so the derivation paths will be m/49'/0'/0'/k/i where k is the change field and i is the address_index. The change and address_index fields remain the same as defined in BIP 44.

It is important to keep in mind that not all wallets follow BIPs 32, 44, and 49. For example, Armory uses its own HD wallet algorithm which predates BIP 32, although BIP 32 support for Armory is currently in the works. Other wallets such as Bitcoin Core and MultiBit HD do not follow BIP 44. Instead they use different derivation paths. For Bitcoin Core it's m/k'/i' where k is change (same definition as with BIP 44) and i is address_index (same definition as with BIP 44).


What's the diffrence between these two bitcoin.conf format?

Answering the second part of your question:
server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands, so you can query it
listen=1 is a bitcoin listening mode
daemon=1 starts bitcoind in the background as a daemon
rpcuser=X and rpcpassword=Q is the user/password for rpc access
rpcallowip=localhost means you can access it through rpc only from your localhost IP machine, add external IP if you want to access it from outside
rpcport=Y is the rpc port to access it (localhost:Y), for bitcoind the default is 8332
AFAIK the second config won't work for rpc, you haven't specified rpcuser, and you will see the bitcoind output in the console (not a daemon).


Ownership of private keys in the Lightning Network

If the third party is routing a payment through your node, only your node and its peers along the payment route need to sign, and therefore only the respective private keys are required. The third party node only signs with its private keys for channel states in its own channel it is routing through (the first hop in the payment route).

If the third party is accessing your node through the server API, then it is necessarily using your node wallet, so it is the private keys hosted on your node which are being used for channel state signing.

Private keys must generally be hosted on an active lightning node, as channel states are updated continuously by the implementation, without user intervention.


Run bitcoinCash on same server with bitcoin

You can create a new username for Bitcoin cash or change default directory.

adduser BitcoinCashUser

su BitcoinCashUser

BitcoinCashd -daemon

Now make sure it has own directory

cd ~/.bitcoin

You should find the files in here.

Change Bitcoin Directory

Follow these instructions on here

Note: kill bitcoin-cash before start it again.

ps ax | grep bitcoinCashd
kill -9 <Process ID>


Generating private key/bitcoin address based on a "password"

What you are describing has been done before, and is known as a "brain wallet".

In earlier days, some wallets and online website did use this system. However, it has proven quite insecure, as humans are terrible at picking secure random data for the "password", and computers are great at guessing them. Many BTC have been stolen from insecure brainwallets, and at this point we have much better and safer means of easily accessing wallets, namely BIP39 seeds.


How to recover wallet by importing private key on testnet?

Testnet uses a different address format than mainnet, you can not view or verifying anything about the mainnet on testnet, they are separate.

You can test your method from the origin by using testnet funds instead.

Alternatively, you can test on mainnet with a small amount of funds to confirm your recovery method is working the same as it did on testnet (which it should).


Can there be more than one result of decoding a raw transaction?

Could decoding a raw transaction ever have more than one solution?

Decoding raw transaction is just a human-readable representation of transaction data. So, the answer is "no" and "yes"

There is only one decoding for transaction.

But another client/version may add some other fields for json


List addresses associated with my wallet in a transaction

listaddressgroupings will show you all the addresses used by the wallet.