Unconfirmed transaction: the status is "0 / unacknowledged, not in memory pool " I started a transaction with bitcoin-0.21.0-win64, a Windows client. It may be that the fee is set too low, which leads to the unsuccessful transaction. What should I do in the future? What do I need to do? How to implement the specific operation steps? Below is the transaction details, please help! Thank you very much！
Status: 0 / unacknowledged, not in memory pool
Date: 2021 / 3 / 8 12:31
To: coin an 1kgsxf7krv1ab99tex1wjm643tsilczbg6
Expenditure: - 0.05193365 BTC
Transaction fee: - 0.00120000 BTC
Net amount: - 0.05313365 BTC
Transaction ID: aceea84e8a72b24654cba7b1d042561d8a9d36f7828855b52012de8a5a0b9c12
Total transaction size: 11767 bytes
Transaction Virtual Size: 11767 bytes
Output index: 0

The transaction you made is quite large, so also if the fee you paid is not low in absolute term, it is in relation to the space taken on blockchain.
0.00120000 / 11767 = 0.00000010

you have paid 10 sat/vByte that was borderline to be included in a block in the days you should have broadcast the transaction.
As you can check here:
https://jochen-hoenicke.de/queue/#BTC,3m,count
there are some transaction with a fee rate similar to your that have been verified (note that it generally takes 14 days for the transaction to be removed from the mempool if not confirmed), so i'm not 100% sure the fee rate is the reason because your transaction has not been verified, maybe there is another reason (eg. when you made your transaction your client is not fully synchronized and you close bitcoin-core before the transaction was actually submitted).

What should I do in the future?

Be sure that your client is synchronized or at least check on a blockexplorer that your transaction just submitted is in mempool (although not yet confirmed).
Enable Replace By Fee so if the fee you set turn out to be too low you can raise it later.
You can also use the bitcoin-core fee estimation choosing recommended transaction fee and setting a confirmation target no longer than a few hours.
Remember to check that the transaction has been verified before 14 days have passed since its submission.


Can one trace the bitcoins to the end Good Day All.

Senario. If i pay ransom-ware to bitcoin address "aaabbbccc". I can tell via blockchain when it goes through. I would just like to know am i able to trace all transactions from wallet "aaabbbccc" to another wallet "xxyyyzzz". then from "xxxyyyzzz" all transactions from then onwards.

And if one can do this, at somepoint the money must make it to real currency and or goods. which must be linked to a person or delivery address.

So if like that why cant they trace the ransomware culpirits.

Thanks very much

There's a core of truth in your question. Indeed, eventually it will reach a point where you can trace it. But there might have been a lot of transactions/hops before that happens.

If it has switched that many hands, how can you be sure that it is still in the hands of the cybercriminals? The money might have been yours but it has been used in quite a few legit transactions. On top of that, finding out the identity of the last person doesn't help in catching the bad guy.


Sharing BIP32 extended master public key I have User A who generates BIP32 Master Public and Private Keys. They share the Master Public Key with User B.

Using the Master Public Key User B generates Address of A and sends bitcoins from Address of B to Address of A.

Will the transaction be received in wallet of User A, if User A knows the index used by User B?

The main idea is that User A don't want to share its receiving address with User B. Instead of that User A must find out itself from the Master Public Key.

That would achieve the expected result, as both User A and User B can derive every possible address from that Master Public Key. It would effectively be the same as User B running a watch-only wallet with that MPK; they have to be able to see all the addresses:)


How do wallets (like jaxx) pair with each other using the mnemonic seed phrase? I'm a bit puzzled on how a wallet pairing process works.
I know you can restore you parent private key from a mnemonic seed phrase. This will give you a parent private key. Using this private key how does a wallet figure out the private/public keys you have derived from this parent key?

Thanks!

You've got everything right. The last step (the one you are referring to) is done by brute force. The wallets just try out many many possibilities until they think they've guessed all the derived privKeys that you actually used. For each possible privKey, the wallet calculates the address and checks whether this address exists on the blockchain ( = there are or were coins on this address).

If you use the same wallet for recovering that also created all the addresses, then the derivation process is obviously the same and the wallet knows exactly how to derive the privKeys, to be sure to "guess" all of them.
There are also standards for how to derive the privKeys:

https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki


IOTA quantum resistance I've read a great deal about the impact of quantum computing on cryptocurrencies in:

https://github.com/theQRL/QRL/blob/master/QRL_whitepaper.pdf
What effects would a scalable Quantum Computer have on Bitcoin?
https://bitcoinmagazine.com/articles/bitcoin-is-not-quantum-safe-and-how-we-can-fix-1375242150/

IOTA also claims to be quantum resistant, unfortunately in their whitepaper that is just briefly mentioned in the last paragraph.

I believe they are talking about the impact from Grover's algorithm where doubling the bit-size help. I can't find any information on how they deal with signatures (which would be broken due to Shor's algorithm) however.

Their wallet code mentions:

  You can use an address for receiving as long as you have not used it for any outgoing transaction. What this means is that once you have sent a transaction with a specific address as input, you should never use it again. This is because IOTA uses Winternitz one-time signatures which degrade security exponentially after each reuse.

So I suppose they are using a Winternitz variant of Lamport's OTS scheme. But how exactly?

I also found an interesting pull request

  In order to prevent the reUse of adresses a message could be display to say that if you re-use the same adresses for transaction the security of your wallet will decrease quadratically .

What does it mean that the "security of your wallet decreases quadratically"? Do they have some Merkele tree with keys to be used? Or how is the relation between address and public/private key in IOTA? If there can only be one transaction with a given input that somehow implies that you always have to transfer all funds?

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).


Longest unconfirmed transaction? I recently tried to make a transaction with coinbase. In a hurry I put no fee though. It's still unconfirmed and blockchain.info doesn't recognize my hash. But my btc qt wallet is debited. My question is what is the longest unconfirmed transaction you've heard of? Mine is going on 16 days. I'm curious because I would still like the transaction to still go through.

A transaction could go unconfirmed indefinitely.

The order in which transactions are confirmed is decided by miners, and generally they will be incentivized to include only the highest fee-rate transactions, to maximize their revenue.

Even a low fee-rate transaction may eventually confirm, once the mempool clears out. But there is no guarantee of this, if the mempool is full for an extended period of time, many nodes may drop the lowest fee-rate transactions from their mempool, to free up memory resources (otherwise, you could DoS attack the network by publishing infinite low-feerate transactions).

Ultimately, once you publish a transaction to the network, you cannot be certain if or when it will be confirmed, until it is. By paying a high fee-rate, you can help increase the chances you will see a quick confirmation. On the other hand, a low fee-rate transaction may never be confirmed, as eventually all nodes may 'forget' about it.

If you have been waiting a long time for a transaction to be confirmed, you could publish a new transaction that spends the same output, but with a higher fee. You may have to force your wallet to forget the old transaction so that it will craft a new one (eg bitcoin-cli abandontransaction "txid" when using bitcoin-core), but not all wallets will include this functionality.


Wallet copay does not function I try to enter in my copay vallet and the screen turn white. What should I do I am from Argentina I try but I can make to function again. I try to formated the cell phone but it does not work

Thanks

Exactly the duplicate of copay does not work in iphone5 ios10
and Copay does not go past splash page ios

Don't worry, it has been reported: https://github.com/bitpay/copay/issues/8382

It's not only you, other people seem to have the same problem.

Just wait until they release a fix for it.


I didnt received funds into my wallet Funds were sent from another wallet to my wallet, but i didnt received the funds, please help

There are many possible explanations and many possible ways to investigate
Possible causes

The sender mis-typed the receiving address. This is hard to do if the
sender scanned a QR code. There are usually checksums built in that
make it hard to get a mis-typed address accepted. Nevertheless it is
possible

You gave the sender a different address than the one you think you did.
This can happen as many wallets issue a different receiving address
for each transaction.

You accidentally gave the sender the address of a wallet that uses
a different crypto-currency than the crypto-currency the sender sent.
This is fairly common. It is arguably too easy to confuse Bitcoin cash
for Bitcoin.

The sender didn't pay a sufficient mining fee

Your wallet is no longer synchronising

You didn't wait long enough

Fraud

If you are using a web-wallet where you depend on a third party, there are also a lot of other ways in which things can go wrong. Especially if the
provider of the service aggregates transactions. (This is one reason I would prefer to use a standalone wallet).
Ways to investigate.

Go to a blockchain explorer website and enter the transaction-ID.
Do the same for the receiving address. Check that your transaction appears.
Check that everything is as you would expect it to be.

Re-check the address you used, letter by letter. re-check the currency.

If your wallet is hosted by a third party, raise the issue with their
customer support service.


How does Electrum protect my Seed? I was reviewing how Electrum wallet protect my seed. They say this regarding seed protection:

  Your seed and private keys are encrypted using AES-256-CBC.

Source: http://docs.electrum.org/en/latest/faq.html#how-is-the-wallet-encrypted

My question:  AES-256 requires a 256 bit key; yet Electrum password's size is 12 characters as per Riaan Swart [1]. Where do the remaining 160 bits come from for the AES-256 encryption key?

Electrum uses hash function on your input to create a key. Now you may be asking what the problem to do a brute force to the short password for all possibilities of hashes and try to crack the key.

Electrum using a hash function, that takes lot of times, to solve. So to create many hashes for brute force it will take forever.


When did Litecoin become "GPU-friendly"? I've heard recently here that Litecoin became more GPU-friendly. When did this happen, and what were the changes to the protocol to accommodate that change. Also, is there any reason for the change provided by the project developers?

Nothing in the litecoin protocol changed, only a tool to mine litecoins using GPU was independently developed: the Reaper and caused difficulty to improve to make CPU mining much less efficient (compared to electricity price). Still, the rise of diffculty is not so dramatic as was the case for bitcoin and scrypt algorithm has proved its worth. CPUs can still mine 1-3 LTC/day at the moment.


What .dat files are safe to be accessed while the Bitcoin client is running? Sometimes one wants to backup some .dat files from Bitcoin, but one can't shut down the client to do so (for example, if one is running a pool). Which .dat files are safe to be copied when the client is running, and which are only updated when the client shuts down?

None of them are safe to access while bitcoind is running.  The only one that is critical to backup is wallet.dat, and the backupwallet rpc command will do that safely while bitcoind is running.


Assuming that the block size fork goes through, will the Bitcoin developers use the alert key to tell people to upgrade? The block size increase proposal currently under discussion would require all clients that process transactions to upgrade.

Otherwise, pre 0.11 clients would reject these larger blocks, leading to a possible double-spend attack against these merchants after Mar 1, 2016.

Will the Bitcoin developers use the alert system to warn these nodes to upgrade?

Yes, according to Gavin Andresen via Reddit.

Even if they didn't to do so, Bitcoin Core already has two other mechanisms which will produce automated alerts as the hard fork approaches: one which will take effect before the hard fork occurs, and one after (as per BIP-50).


Best Practices for hardened keys in HD wallets? Essentially, I am seeking to know where in an HD wallet tree structure should hardened keys be used. For example:

Shouldn't all child keys of the master extended key be hardened?
Should all extended public keys that are shared have the immediate parent key be a hardened key to ensure that a single compromised key doesn't compromise other keys?
Should the whole HD wallet tree structure use hardened keys except for the leaf node keys?

The simple (and I believe correct) answer is: use hardened keys everywhere except where a need for watching-only wallets is perceived, e.g. below the "account" level. A watching only-wallet in this scenario will be able to both create new addresses, and monitor the balance of an account.

Hence BIP-44's path is:

m/44'/0'/account'/change/index

The clear result is that each account's xpub must be exported separately from a cold wall for import into a watching-only wallet.

Almost every wallet I've looked at uses this method (the exception being Wallet32 for Android prior to v0.2.5 released May 15 2014). Reference: this bitcointalk post, which links to this spreadsheet.

edited to add: Also of some relevance is the level at which an xpub is exported. Almost every wallet which supports xpub exports does so at the account level (same reference as above), which includes both the external and internal (change) chains of a single account. (The exception is MyCelium for iOS, however this is considered a bug by the MyCelium devs.)


How do services like ShapeShift generate new addresses I found that ShapeShift generates new address for each transaction. How do they do that? Is it possible to exchange the coins in the same manner as ShapeShift do, but without the creation of new address?

This is called Hierarchical Deterministic key derivation.

New public keys, and by extension Bitcoin addresses, can be generated from a set of parent public keys. This way, the front-end of Shape-shift never needs to communicate with a "hot wallet" and can generate a new set of addresses for every user transaction.

To spend from these addresses, Shapeshift simply derives the corresponding private key (server-side) from its parent private keys.

Child private and public keys can be derived in parallel (front/back-ends), maintaining a fire-wall between them.

Intro to HD Wallets

For details on HD key derivation works, check a recent talk of mine at Scaling Bitcoin: https://youtu.be/OVvue2dXkJo
Slides here: https://teachbitcoin.github.io/wallets.html#/5


bitcoind sendfrom with minconf=0 Is it possible using bitcoind JSON-RPC API to receive funds from someone and send it immediately to another third-party address? I do not want to wait for 1 confirmation.

getbalance with minconf=0 shows I have 0.01 BTC, but when I do sentfrom with minconf=0, I get Insufficient funds error.

From the help for the sendfrom RPC/command line command:

  Arguments:

  "fromaccount"       (string, required) The name of the account to send funds from. May be the default account using "".
  "tobitcoinaddress"  (string, required) The bitcoin address to send funds to.
  amount                (numeric or string, required) The amount in BTC (transaction fee is added on top).
  minconf               (numeric, optional, default=1) Only use funds with at least this many confirmations.
  "comment"           (string, optional) A comment used to store what the transaction is for.
                                   This is not part of the transaction, just kept in your wallet.
  "comment-to"        (string, optional) An optional comment to store the name of the person or organization
                                   to which you're sending the transaction. This is not part of the transaction,
                                   it is just kept in your wallet.

Parameter 4 is for minconf. You can't just add minconf=0 to the command, though, you have to give arguments for the first 3 parameters and then specify the 4th. For example:

sendfrom "" "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" 0.1 0

If that still doesn't work, make sure the funds show up in getbalance "" 0. Also note that you need to leave some for a mining fee (you actually need a little bit more than the amount you want to send in order to make a transaction go through, because of the fee).


Can I recover my seed words? I am using MultiBit Ver. 0.5.14, I have my wallet open in it, but do not know my seed words, I had them saved most likely on my computer or printed out on paper, but after 3 moves, 2 computer crashes and 1 computer replacement I have no idea where they might be or what they are, can I recover them, if so, how?

Thank You

Michael Grace

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

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


Bitcoin testnet not connecting to hardcoded ip addresses I am trying to force bitcoind running in testnet mode to connect to my own defined set of ip addresses(basically 127.0.0.1:diffPorts). For this I have disabled dnsseed and starting with a fresh installation of bitcoind.

Currently I am trying to simulate 4 nodes on a local machine, such that all 4 are hardcoded into the chainparamseeds file as follows:

static SeedSpec6 pnSeed6_test[] = {
    {{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x7f,0x00,0x00,0x01}, 18441},
    {{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x7f,0x00,0x00,0x01}, 18442},
    {{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x7f,0x00,0x00,0x01}, 18443},
    {{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x7f,0x00,0x00,0x01}, 18444}
};

My debug.log output ends as follows:

2015-10-22 11:53:43 Loading addresses from DNS seeds (could take a while)
2015-10-22 11:53:43 net thread start
2015-10-22 11:53:43 0 addresses found from DNS seeds
2015-10-22 11:53:43 init message: Done loading
2015-10-22 11:53:43 addcon thread start
2015-10-22 11:53:43 dnsseed thread exit
2015-10-22 11:53:43 opencon thread start
2015-10-22 11:53:43 msghand thread start
2015-10-22 11:54:44 Adding fixed seed nodes as DNS doesn't seem to be available.

I expect the nodes should have connected to each other after the last line indicates that fixed seeds have been added, but that does not happens. Can someone guide me what am I missing here ?

These are seed nodes, not nodes that are connected to for a connection. A seed node means that it is a node that will be connected to in order to get addresses of other nodes to connect to. That connection will not be maintained; rather it is temporary.

If you want to connect nodes to each other, you should not be modifying the seed nodes at all. Rather you should be using the -connect=<ip> option (or add it to your bitcoin.conf file) to connect only specific nodes.


How to block a Ripple account from a Gateway's perspective? I heard a few months back that Ripple enabled users to set their account to block other accounts from holding their IOUs. A feature probably aimed at Gateways to be able to freeze balances of blocked users and so forth. I am wondering, is there a documentation and a step-by-step guide for this functionality available anywhere?

You seem to start out describing the "Authorized Accounts" feature of Ripple, but then you then pivot to freezing.

Authorized accounts which allows an issuer to explicitly approve which accounts may hold his issuances. The feature is described here: https://wiki.ripple.com/Authorized_accounts.

The "freeze" feature Ripple allows issuers either globally freeze all their issued funds or to freeze funds issued to a particular user. Frozen funds may only be sent back to the issuer. The feature is described here:
https://wiki.ripple.com/Freeze.


Bitcoins and transactions missing I had a wallet which had approx $660 worth of bitcoin somewhere around 0.05 BTC and all of a sudden it has vanished and my transaction tab shows nothing.

I have put my receiving address into the block chain and it shows that a transaction sometime in March of 2019 was made and I didn't make any transactions in March of this year. How odd. Anyway this has blown my mind and I don't know who to ask for help or what to do ?

Any ideas or can someone be of assistance? I really don't know what to do. In addition, I was thinking that maybe bitcoin had plummeted on the market and maybe it lost value and that's why maybe I have none but to be fair there was enough bitcoin in my wallet but no nothing.

Am I doing something wrong and it is safe for me to paste my receving address here for someone to take a look or is that a bad move ?

I only use my bitcoin to pay for VPN and it does show that I renewed my VPN in august which is when I did make a transaction so why it is showing a transaction in March 2019 makes no sense whatsoever.

I've read that something does cause bitcoin to appear as vanished but to be fair I've re-synced which took over 24 hours and I created new receiving addresses which I read can sometimes re-gig the system and your available bitcoins appear.

Nothing?

Any ideas ?
Thanks
KC

Any ideas or can someone be of assistance? I really don't know what to do

TL;DR:  Your money has been stolen. There is nothing you can do that has any significant probability to recover your $660.

The thief got access to the private-keys stored in your wallet.

  a transaction sometime in March of 2019 was made and I didn't make any transactions in March

One possibility is that someone gained access to your wallet and stole your money.

One recent issue was with the Electrum wallet.

However, if you have a PC wallet or access an online wallet from a PC it is always possible that other malware on your PC stole your passwords and used them to access your wallet, steal money and finally erase logs and data to cover their tracks.

  I have put my receiving address into [a] block chain [explorer]

Most modern wallets are HD wallets that create a new receiving address for each transaction.

  I created new receiving addresses which I read can sometimes [make] your available bitcoins appear.

I've not heard of this, it would have to be a bug in a specific wallet. In general I would be surprised if this helps.

If you found unexpected transactions in a blockchain explorer, it is unlikely that there is a fault in your wallet software. More likely you are a victim of theft.

If your wallet is misbehaving. One solution is to make a careful copy of your seed-words or your private key (you should have these already in a safe place), then use those on a fresh computer (or phone etc) to download and install the wallet software from the only genuine trusted website and make a new duplicate wallet and let it synchronise fully. You don't need to erase your old wallet until the new one is working fully.

  it is safe for me to paste my receving address here

Yes.

There are potential privacy issues if you only use one receiving address. Anyone can see a list of all the transactions made involving that address. But it doesn't give anyone any way to access your money.

You can also safely publish a transaction id and the name & version number of your wallet software (e.g. bitcoin-core 0.18.0, electrum 3.3.4, ...)

Never give anyone your private key, your seed-phrase / recovery-phrase or the password to your wallet or online wallet or account. Changing a previously disclosed password does not re-secure your wallet/account.

  Also this is what I read regarding created a new address can sometimes show balances again: reddit.com/r/Iota/comments/6sim7o/

That advice relates to IOTA not to Bitcoin.

  I'm positive that I never used bitcoin this year

Everything suggests your Bitcoin was stolen.

I wouldn't use that wallet again and I wouldn't use that PC for any new wallet or any further financial activity again. Even after zeroing the disks and cleanly reinstalling the operating system, I'd worry about BIOS malware, infected USB devices, etc.


Where can I get a list of stale RBF'd transactions? I would like to prove that a certain transaction was in the mempool on a certain date before it got replaced via RBF with another transaction. Is there any service that provides this data?

I would like to prove that a certain transaction was in the mempool on a certain date before it got replaced via RBF with another transaction.

Consider Tx de8ba282831c6d645aa777a35a5b9f2107cbd96913a9cd4c5880420db092e399 as an example.
gettransactionin Bitcoin Core returns:
"time": 1615601043,
"timereceived": 1615601043,
"replaced_by_txid": "f77e6928c1c12bc91858c95b32dab1e493b24cdf3e19c02372aa11e6dc5ec3c9",

Time of this tx: Saturday, March 13, 2021 2:04:03 AM
Got replaced by another tx on: Saturday, March 13, 2021 2:04:11 AM
I am not sure but maybe this information is only available for transactions that belong to your wallet.

Is there any service that provides this data?

Couldn't find such information in any of the famous bitcoin explorers. Best I could find was one explorer that shows invalid type for tx which got replaced:
https://tbtc.bitaps.com/de8ba282831c6d645aa777a35a5b9f2107cbd96913a9cd4c5880420db092e399


Why do I have a socket.timeout with python-bitcoinlib? I am using a small script and get a timeout from python. This is my script:

import bitcoin
import bitcoin.rpc
from bitcoin.rpc import RawProxy
p = RawProxy()
hash = '0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4'
infoblock = p.getblock(hash)
print(infoblock['difficulty'])

This is my error:

bitcoin@raspberrypi ~/.bitcoin/BuchSkripte $ python3 49_rpc_example.py
Traceback (most recent call last):
  File "49_rpc_example.py", line 11, in <module>
    infoblock = p.getblock(hash)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 306, in <lambda>
    f = lambda *args: self._call(name, *args)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 236, in _call
    response = self._get_response()
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 261, in _get_response
    http_response = self.__conn.getresponse()
  File "/usr/lib/python3.5/http/client.py", line 1198, in getresponse
    response.begin()
  File "/usr/lib/python3.5/http/client.py", line 297, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.5/http/client.py", line 258, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.5/socket.py", line 576, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

When using the same method getblock via bitcoin-cli it takes 120 seconds to finish on my Raspberry. If the timeout is related to this duration, can I increase it in the script?

I read that the socket timeout can be set but I wonder if I can do this if I use a library for the connection.

Change the timeout inside the file bitcoin.conf or when you start the bitcoind,

This is an example

##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##
# On client-side, you add the normal user/password pair to send commands:
rpcuser=alice
rpcpassword=bob
rpcclienttimeout=200

or you can run the bitcoind with this command bitcoind -rpcuser=alice -rpcpassword=bob -rpcclienttimeout=200

Or you can change the setting lib to the code, try this example

from bitcoin.rpc import RawProxy

# Create a connection to local Bitcoin Core node
p = RawProxy(None, None, None, 120)

# Run the getblockchaininfo command, store the resulting data in info
info = p.getblockchaininfo()

# Retrieve the 'blocks' element from the info
print(info['blocks'])


What is the difference between the rpc port 8332 and port 8333? What is the difference between the protocol and commands used on default ports 8332 and port 8333?

From what I gather, port 8332 is the RPC port, it's "sensitive", only allowed by local host by default, and it has one username & password.

On the other hand port 8333 is some kind of P2P port that is used with Bitcoin transaction replication.

Can anyone clarify the official names, purposes, and security of each of these ports?

Which one uses JSON, and which is Binary?

The Bitcoin.org client will try to communicate to other nodes via port 8333 and those communications follow the Bitcoin protocol.   If an explicit connection is given (IP address and port) the port setting can be overridden to use any port.

The bitcoin.org client can be configured to accept JSON-RPC communications, and when that is enabled will, by default, be on port 8332.  Earlier versions of Bitcoin Core permitted this to be secured with SSL communications using the same port or a different port, however that capability has since been removed.


Do I understand correctly that mnemonic seeds are specific to individual wallet software and its versions? I know mnemonic passphrases are used to derive a master key that can then be used to procedurally generate your addresses. If you lose everything except the mnemonic, you can regenerate everything and recover your losses.

But from what I understand, and as my limited experimentation has shown, these mnemonic seeds seem specific to an individual program and even its versions.

So let's say one day I lose everything except my mnemonic and I decide to recover it all. I set up my a new pc and such, and look for a wallet program. My original program is no longer available because nyan cat ate the source code. Am I now not basically screwed because any alternative program won't be able to process my original mnemonic seed?

So if I want to not take any chances and not be bound to any single platform, I shouldn't focus on the mnemonic but on my master key, which I'm merely presuming is standardized and universal. Having to store this single long string of pseudorandom chars isn't exactly an improvement over storing a csv of pseudorandom strings, is it?

And of what I've seen, programs like even electrum and mycelium are all but crystal-clear about what exactly you are backing up and what exactly you can do  with it (on mobile - electrum is much clearer on desktop, though it still doesn't say anything about the nature of the mnemonic for example). A button labeled "back up my wallet" doesn't really tell me if I'm backing up either type of seeds or just a list of keys, or something else. I suspect a binary file specific to this wallet program at that moment. Programs relevant to the same thing (i.e. wallet programs) should really carry labels on all their features, pointing out what is universal/standardized/cross-platform and what isn't.

There are standards.  You would have to check that your particular wallet program conforms to them.

The standard for converting a mnemonic passphrase to/from a seed is BIP 39.  The standard for generating keys from a seed is Hierarchical Deterministic Wallets, BIP 32.


Broadcast raw transaction without input validation What tool/software can I use to broadcast a raw transaction, which would not reject a transaction because of invalid or double spend?

Bitcoind with RPC has a validation step which rejects any raw transaction where the inputs are not known, or if the inputs are double spending.

Also, I don't want to rely on a third party service like blockchain.info.

Turns out there are many ways to do this:

Node.js: Bitcore lets you broadcast a raw transaction to the network without any kind of validation, see the "broadcast a transaction through P2P" example.
Python: Protocoin is a library that can do that.
Java: BitcoinJ can do it.
C#: Bitcoincsharp, which is a port of BitcoinJ can also do it.


Why does Electrum keep creating receiving addresses? Everytime I open Electrum up, a new address for receiving is generated.
Why is this happening? Is it supposed to generate so many addresses?
I have over 20 receiving address at the moment.
This seems to happen every time I start up Electrum for the first time after boot.
Any insight would be greatly appreciated!

Electrum allow you to create HD wallets that use seed to generate a near infinite amount of addresses.
All bitcoin addresses are public so it is better to use different addresses each time you receive coins for privacy reasons
Here is the official answer to your question from electrum: https://bitcoinelectrum.com/frequently-asked-questions/#why-does-electrum-give-me-a-different-address-everytime


What prevents bitcoin from breaking down in case of a "transaction attack" Let's say that I want to kill Bitcoin by means of a transaction attack. What in the bitcoin system prevents the following approach:

I buy a limited number of bitcoin in the market.
Using a small number (say 50) physical computers all running bitcoin clients and accessing the net through proxies, I generate, say, 100.000 wallets - each with their own bitcoin addresses.
(Running a script on the computers) I start sending random amounts (mili-to nanobitcoin range) of bitcoin back and forth between all my 100.000 (or more) wallets - each at a very high frequency. Average flow of bitcoin between wallets average to zero.

This causes an explosion in the number of daily transactions (currently in 1,000-10,000/day) range to millions or billions of transactions.

This makes every block gigantic in size causing an explosion in the blockchain and causing widespread problems with blockchain verification, storage and (worse) synchronization => the network dies.

Can someone explain why bitcoin is immune to this kind of "transfer attack"?

There are rules which make such kind of attack very costly to the attacker. Below are relevant rules from wiki, with updated transaction fee:

0.0005 BTC fee per kilobyte of transaction, but:

If the blocksize (size of all transactions currently waiting to be
included in a block) is less than 27 kB, transactions are free.
If the blocksize is more than 250 kB, transactions get increasingly
more expensive as the blocksize approaches the limit of 500 kB.
Sending a transaction when the blocksize is 400 kB will cost 5 times
the normal amount; sending when it's 499 kB will cost 500x, etc.

Let's say attacker publishes 499kB worth of transactions every block, this would be about 1000 transactions per block, 144000 per day. This is nowhere close to millions or billions, and besides it would cost him about 18000 BTC per day.

Source: Transaction fees


When a difficulty change reaches the upper or lower bound (4x current), what is the implied impact on time per block? Can someone work out the math that occurs with Bitcoin and Litecoin when the target changes to the hard coded minimum and maximum value, with respect to time?

In other words, if a lot of hashpower is added to the network and target increases by 4x, that is the upper bound.  How many blocks can be created right before the throttle of 4x is taken by the network?

I'm trying to calculate the affect throttling has on the number of blocks generated per hour.

Question

  What is the average time per block, right before the network adjusts to the 4x limit, when the hash power is added to the network?

If I were to guess, right before that 4x limit was reached, 1 block is generated every 2.5 minutes for Bitcoin, and 1 block every 45 seconds for litecoin.

Furthermore any hashpower added (or removed) beyond the 4x multipler will not cause a network adjustment and infinitely many blocks may be created in that interval.

Why I want to know this...

If a lot of hashpower is added to the Litecoin network, which already generates blocks (one every 2.5 minutes) then there will be more blocks generated, increasing the risk of a chain split.

I ultimately want to understand how the chain split will cause wasted computation by peers as their blocks are discarded by the longest chain.

The network doesn't "throttle" the blocks found. Rather, it simply doesn't change the difficulty by a factor of more than x4 in every adjustment (which is once every 2016 blocks). There is no limit on the rate of block generation.

Let's say you were in an equilibrium where a block is found every 10 minutes. Right after a difficulty adjustment, more power joins the network and the hashrate is x100 the original. The difficulty didn't change yet so now a block will be found every 6 seconds. This will go on for 2016 blocks (~3 hours) and then the difficulty will go up by x4. Now a block will be found every 24 seconds; after 2016 more blocks (~13 hours) the difficulty will go up again by x4. Then a block will be found every 96 seconds, for 53 hours; then a block will be found every 384 seconds, for 215 hours; then the hardcoded limit will not be active, the difficulty will go up by a factor of (600/384), and now a block will be found every 10 minutes.

In those times that the total hashrate is too high for the current difficulty, the level of forking will be as if the time constant was shorter. So forking will indeed be high if the total hashrate has just rapidly increased.


Does rootstock need segregated witness to work? Does Rootstock need segregated witness or any other bitcoin improvements not currently included for it to work?

No, Rootstock does not need segregated witness.
Yes, Rootstock does need another Bitcoin improvement not currently available on mainnet.

Details below:

Rootstock & segregated witness

Segregated witness (segwit) eliminates all known third-party transaction malleability, which is an extremely useful feature but something that's only required in cases where a transaction has to be created before all of its parent transactions have confirmed.

For example, in a Spillman-style payment channel, the refund transaction is created and signed before the deposit transaction is broadcast---which is dangerous because if the deposit transaction is mutated (malleated), the refund transaction becomes invalid.

However, for a two-way pegged merged-mined sidechain like Rootstock is planning to use, the design makes the peg transactions robust against double spending (by waiting for many confirmations) in a way that also makes them robust against malleability.

Segwit also increases the maximum possible transaction size, which can make it more a bit more affordable to use sidechains, but not in any significant way and it isn't a requirement.

Rootstock & other Bitcoin improvements

Rootstock wants to use a two-way-peg merge-mined sidechain (also called a decentralized sidechain).  There is no current know way to do this with just the opcodes currently enabled on Bitcoin mainnet, so this is not possible today.

Broadly speaking, there are a few different proposed approaches to enable this:

Extend Script's flexibility: add one or more generic opcodes to the Bitcoin Script language to allow it to validate what are called SPV proofs or merkle proofs---the kind of data that SPV clients use today to determine if a transaction is part of a chain of block headers.
Add a special SPV proof opcode: give Bitcoin Script the ability to directly validate SPV proofs.  This would make the sidechain contracts simpler and cheaper, but to some engineers it feels a bit weird to add opcodes specialized for one purpose.
Add a special reverse peg opcode (drivechain): give Bitcoin Script a special opcode that says, "I trust miners".  Anyone who pays this opcode allows miners to spend those funds however they would like; then arrangements could be made with miners to only spend that money if they followed the sidechains rules.

At least one of the approaches above would need to be enabled for Rootstock to follow their plan; Rootstock's current preference is for #3, drivechains.

It's worth noting that if Rootstock wanted to use federated-pegged (fedpeg) sidechains, such as those implemented in the Elements Project, then no changes would be required to Bitcoin today.  However, fedpeg sidechains rely on trusted signers for every block and so are not decentralized.


How do I iterate through the entire Blockchain using RPC? I'd like to iterate through the entire block chain using RPC.  The process I intend to do is:

getblockhash 1
getblock (input of #1 here)
iterate through each transaction with GetRawtransaction (input of tx field here)
After getting all transactions, call getblockhash 2 (or goto nextblockhash in block)

I just want to make sure I'm enumerating the chain correctly

Your plan is correct (use getrawtransaction <hash> 1 to get JSON instead of HEX :D) but the RPC becomes slow > 60% of the blockchain because there's between 500 and 2k transactions to go through.
Make sure txindex=1 is in your config so it has the rawTX data.

As suggested by George parsing the raw files stored will make a very significant difference, to save you a lot of work;
this project (by bitpay) already does a that nicely:
https://github.com/bitpay/insight-api


At what point does the criminal get caught? Settle an argument for me.
Assume a criminal does the following:

1: goes thru trash to find a cancelled check
2: using a wifi hotspot like McDonald's and "Hide my ass" buys bitcoins with stolen bank info
3: sells bitcoins and transfers money to his personal account.

Which step does he get caught?

My friends says he gets away with it, I say he gets caught when he sells them. Who's right?

Most sites that sell Bitcoin for cash require more information than just "bank info" in order to run the transaction.  So the scenario you outlined is not quite complete for the purposes of "not getting caught".


Where can i find proof of work in Electrum(light weight bitcoin) source code? Hi does anyone knows where can i find electrum's proof of work in the source? https://github.com/spesmilo/electrum

Miners perform the proof-of-work that secures the blockchain. Electrum is not a miner.

Electrum is a light wallet, it does not perform proof-of-work hashing to create blocks, instead it just checks to ensure that relevant transactions are valid. Rather than download the entire blockchain, it will just download the block headers (much less data), and then it can perform cryptographic checks to ensure that everything is legit.

For transactions in particular, the wallet will ensure that the relevant transaction hashes are present in the merkle root of a block (the merkle root is part of the block header). The wallet can request the relevant transactions, and then hash them to verify that the correct merkle root is reached (ie, the same merkle root that is present in the longest valid proof-of-work chain). Due to the one-way nature of hash functions, a node could not serve an invalid transaction hash to a wallet, or else the root would change entirely and the wallet would know it is invalid.

In this way, light wallets allow you to verify the blockchain's history with a low level of trust, and low resource intensity (less data, and less verification computation).


Are Bitcoin's blocks signed by the miner? To my understanding, at no point in the Bitcoin Whitepaper does it say that blocks are signed by the miner. However, one could see the advantage of having blocks signed.
Thus I wonder if in the implementation of Bitcoin, blocks are signed by miners? Or maybe I missed it in the Whitepaper?
Thanks!

A sort of. Not a cryptographic signature, but each miner is incentivized to use one of its own BTC addresses as recipient of coinbase (reward) transaction. This links the block to the miner, with the same strength each UTXO is linked to its owner (I want to stress that there isn't native identity concept in bitcoin's blockchain, so we can say that the attribution allowed by core methods is already implemented)
Can you elaborate on signature (maybe stronger one) advantages, from your POV? Thanks


While verifying previous blocks, how does the node know the difficulty at nth block? A full node has the capability to verify every block starting from the genesis block up until the last block. It does this by hashing the block header and checking if the hash recorded in the block is same as the computed hash.
Except, the difficulty is not fixed and the number of leading 0s needed are different in different blocks. How does the validating node know that the nth block required k 0s at the beginning of the hash?

eg: An attacker can build an entire blockchain with initial blocks having only 2 or 3 0s which would be easy to compute. The blocks would be valid as the computed hash will match the recorded hash.

Contrary to popular belief, the difficulty is not actually based on the number of leading zeros, that's just an oversimplification to help people understand what difficulty is. Rather the difficulty is based on the value of the block hash when interpreted as an integer. The difficulty of a block must be less than or equal to a target value. The target value is adjusted every 2016 blocks and is encoded in a compact form in every single block (it is part of the block header).

When a node is syncing, they start with the target value encoded in the genesis block. Every 2016 blocks, a very simple algorithm is run to calculate the target value for the next 2016 blocks. This algorithm is deterministic, so given the same set of blocks, all nodes will result in the same target value calculation. In this way, a node which has validated from the genesis block can know exactly what the target value for the nth block in the blockchain must be.


No inbound connections on my bitcoin full node with TOR Can someone connect to my running node? u3ob433qu3ebkmsu.onion:8333

I'm behind a CG-NAT so I've thought using TOR would solve my problem.

I had my node running for hours but no inbound connections.

grep debug.log -e inbound returns nothing.

$ bitcoin-cli getnetworkinfo

{
  "version": 180000,
  "subversion": "/Satoshi:0.18.0/",
  "protocolversion": 70015,
  "localservices": "000000000000040c",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 10,
  "networks": [
    {
      "name": "ipv4",
      "limited": true,
      "reachable": false,
      "proxy": "127.0.0.1:9050",
      "proxy_randomize_credentials": true
    },
    {
      "name": "ipv6",
      "limited": true,
      "reachable": false,
      "proxy": "127.0.0.1:9050",
      "proxy_randomize_credentials": true
    },
    {
      "name": "onion",
      "limited": false,
      "reachable": true,
      "proxy": "127.0.0.1:9050",
      "proxy_randomize_credentials": true
    }
  ],
  "relayfee": 0.00001000,
  "incrementalfee": 0.00001000,
  "localaddresses": [
    {
      "address": "u3ob433qu3ebkmsu.onion",
      "port": 8333,
      "score": 4
    }
  ],
  "warnings": ""
}

bitcoin.conf

server=1
daemon=1

# RPC
rpcuser=*****
rpcpassword=*******

# TOR
onlynet=onion
proxy=127.0.0.1:9050
bind=127.0.0.1
dnsseed=0
dns=0
addnode=nkf5e6b7pl4jfd4a.onion
addnode=yu7sezmixhmyljn4.onion

# Raspberry Pi optimizations
dbcache=100
maxorphantx=10
maxmempool=50
maxconnections=40
maxuploadtarget=5000
prune=6000

It generally takes a long time before the network "discovers" you're a good peer to connect to. It may be a few days before you get inbound connections.

I'm able to connect to you.


Does, or will, Bitcoin Core support Lightning? I vaguely understand what Lightning is, and would like to take advantage of it. However, actually using it seems extremely "fuzzy".
If it requires some separate software to be trusted, installed, configured and maintained, then I'm afraid it's off the table for me.
I already run Bitcoin Core. Will that get built-in support for Lightning? Or maybe it already has it?
I'm very worried that potentially large fees will prove a major obstacle in front of potential paying customers who don't want to spend so many satoshis just to make such a small payment to my service. I wouldn't want to pay the same amount in fees as what the service costs, myself. That's why Lightning appears to attractive to me, regardless of the speed.
If this thing is going to remain an "add-on", which you need to separately worry about and fiddle with, I'm afraid it will go the way of the Sega 32X or Mega CD. I really hope that's no longer the case, or at least won't be for much longer.

A sketch of Lightning Network support was previously proposed to Bitcoin Core.
Conceptually, most contributors think it is outside of the scope of the Bitcoin Core project which should be limited to be a robust backbone for the Bitcoin network.
Lightning Network implementations "on top" of Bitcoin Core already exist, the three most mature ones being C-lightning, LND and Eclair.
Given the complexity of the Lightning Network, specialized softwares are in my opinion required.


Even though Blockchain is tagged as " Decentralized", wouldn't the organization actually implementing the Blockchain like Ethereum control it? For example, If I were a business that would want to use the Ethereum Blockchain technology to shift my business to Blockchain, wouldn't Ethereum be in control of the actual underlying Blockchain technology? Wouldn't it have the power to for example change the consensus algorithm or change the underlying technology? If I am missing something here please explain.

"Decentralized" is really a hybrid of distributed and centralized:


What development tests should I do when creating a Base58Checked parser? Are there any special tests (test data) I should run against my code if I've written a Base58Checked encoder/decoder?

I'm using BigInteger in .NET so these tests are unique to this scenario but may be adapted to Java or other languages.

The tests I've found helpful is when translating to or from hexadecimal at any intermediate step make sure the data is correct when:

The first or last byte of the checksum is one or more 0's
The first or last byte of the address is one or more 0's

Often times this may cause two's compliment errors depending on the implementation of BigInteger that is being used.

I'll run my own version of vanity gen to generate addresses that have these errors and will post them here.


Bitstamp streamline API: how to get all contents of the ordebooks? I've been trying to work with Bitstamp streamline API, which uses Pusher.

So I managed to connect to some channels, specifically to 'orderbook' and it even returned me 6 items. However it looks like some kind of limit. Does anybody know how do I get the full contents of the orderbook (that is, all orders) throught this streamline API? (I know you can do it via regular REST api, but due to some limitation, I really have to use Websockets and Pusher in this case).

I haven't yet used Bitstamp's streaming API but I think it's fairly safe to assume that you will only get real-time changes via those pusher channels. That means you need to make at least one initial call to their official REST API to get the full orderbook, and then keep it updated by applying the changes that you receive from the streaming API.

If you are really stuck with websockets only (care to explain why?), you may need to build your own proxy middleware that can make that initial REST call and feed your client with the full orderbook via websockets.

Either way, be extra careful about relying on an unofficial and unsupported API which Bitstamp can change at any moment without prior warning.


lightning daemon rejects bitcoind RPC variables in lnd.conf I run lnd and bitcoind under their own users, but on the same physical machine. This means lnd has trouble accessing the bitcoind .cookie, so I'm trying to configure lnd to use RPC.

When I use the following options in my lnd.conf as described in the lnd documentation:

bitcoind.rpchost=127.0.0.1:8332
bitcoind.rpcuser=joeblow
bitcoind.rpcpass=superSecretPasswordByRPAUTH.py
bitcoind.zmqpubrawblock=127.0.0.1:28332
bitcoind.zmqpubrawtx=127.0.0.1:28333

lnd errors out with the following error:

lnd.conf:16: unknown option: bitcoind.rpchost

lnd runs fine if I specify the above options using the command line like this:

lnd -bitcoind.rpchost=127.0.0.1:8332 -bitcoind.rpcuser=joeblow ... etc

This means typing in the RPC password in the command-line and command-line options can be seen by users running 'top' or task manager. This exposes RPC password to users other than 'lnd.' Having RPC password in lnd.conf is moderately more secure because the file can be locked down with chmod.

Found out that any bitcoind.XXX options need to be under a [Bitcoind] heading. Working lnd.conf is as follows:

[Application Options]
debuglevel=info
debughtlc=false
maxpendingchannels=5
alias=WittyAlias
color=#000300
maxlogfiles=3

[Bitcoin]
bitcoin.active=1
bitcoin.node=bitcoind
bitcoin.mainnet=1

[autopilot]
autopilot.active=1
autopilot.maxchannels=16
autopilot.allocation=0.1

[Bitcoind]
bitcoind.rpchost=127.0.0.1:8332
bitcoind.rpcuser=wittyusername
bitcoind.rpcpass=VerySecretSuperDuperRPCauthPassword
bitcoind.zmqpubrawblock=127.0.0.1:28332
bitcoind.zmqpubrawtx=127.0.0.1:28333


What is the point of adding transation to block chain What is the advantages of adding transaction into the blockchain, instead why can't we go with a normal current way of validating the transaction through dollar, rupees so on.

Is there any advantages of using transaction using blockchain?

Is it more secure or less secure?
 Is it faster or slower? I felt is slower?

Are we going for it is just because we need to use cryptocurrencies?

What is the advantages of adding transaction into the blockchain

preventing doublespends

for more informatoin look to https://en.wikipedia.org/wiki/CAP_theorem (Partition tolerance)


Are redeemScripts private? When I do createmultisig in bitcoin core, I get the redeemscript as output. I of course want to save this information, but can I put this in my regular database or do I need to take extra precaution with the redeemScript?

In Short: Should I treat the redeem script as a private key, public key, or address hash (what level of security/and do i need to treat it with). This is from a "if it get stolen" perspective. What is the worst thing someone can do with a redeemScript?

You can treat the redeemScript as the public key. The redeemScript, like the public key, is revealed entirely when you spend from your multisig address. So it will become public information, much like your public key will also become public information when it is used in an input.

The redeemScript cannot really be used to do anything particularly bad unless the redeemScript has certain conditions which allows someone to do so. For multisig, there are no such conditions. Having the redeemScript only allows you to see what the specific conditions for spending an output are, and that information by itself is not useful.


Understanding "anonymous transaction" I have read

  In the original Satoshi whitepaper, it was recommended that Bitcoin
  users use a new address for each transaction to avoid the transactions
  being linked to a common owner.

But in reality, when A buys a bitcoin from B, A sends money to B to B's account in an exchange (or whatever account.) It seems that B can be identified via this dollar transaction by an exchange or the authority?

The original Satoshi client (now called Bitcoin Core) was developed from the whitepaper. Exchanges, online hosted wallets and many other things requiring identification came later. You can still run Bitcoin Core or a similar wallet on your desktop and many people value the anonymity.

You are right that when you use an exchange or another service where you are required to identify yourself, link bank accounts or, other similar activities you can be identified.


What does "peer sent transaction already received" mean? This is  my output from p2pool.

2013-07-10 16:06:29.543000 P2Pool: 17383 shares in chain (17388 verified/17388 total) Peers: 11 (5 incoming)
2013-07-10 16:06:29.544000  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-07-10 16:06:29.544000  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2013-07-10 16:06:29.544000  Pool: 1074GH/s Stale rate: 17.1% Expected time to block: 23.7 hours

Problem - Why are there '???'s replacing all the values?

Question 1 - What does the 'Peers: 11 (5 incoming)' mean

Question 2 - What does the following line mean? It shows up a lot with different strings of numbers and letters:

2013-07-10 16:10:01.362000 Peer sent entire transaction 59900f72264267f0fbff2041ea50d9b72ba44448aa2244429e855f5372ba2bca that was already received

Thank you for your time.

The "???"s mean that P2Pool has no estimate because nobody is mining on this node. "Peer sent entire transaction ..." is printed when a little bandwidth is wasted because peers are forwarding transactions needlessly.


BlockChain Network With all Fake Nodes How can I know if the blockchain network is with all fake nodes.What if i create my block network with all my fake nodes to validate transactions?

-- dropping this in the answer secton, cause too many characters for comment section ---

certainly you can create your own blockchain, and create all your own fake nodes. But why would someone join your network? What is the value?

Bitcoin blockchain is currently managing ~19 billion US$, and must assure, not too many fake nodes "come in". In this case, the network is protected by +5000 other nodes, and many mining nodes to ensure proper functionality of the network. I recommend reading "https://bitcoin.org/en/how-it-works" or it's translations, especially the link to the mining section, and "Going down the rabbit hole". As this here is more a development oriented area, it might be better to discuss such question in a forum like "https://bitcointalk.org/index.php".
Hope this helps :-)


Help with missing transaction I'm trying to learn how to programmatically interact with the Bitcoin protocol. I've, seemingly, successfully generated a private key, WIF, and public address with code. I used Coinbase to send .001 BT to 14egr6kfYY4xiSVPim2sJnED4t89Yvn8hQ. I then used the Bitcoin-Qt debug console and issued

walletpassphrase <WIF> More

to import the address. The address has shown up in Bitcoin-Qt but the transaction is not appearing.

Any help is greatly appreciated!

As others have stated, doing

Bitcoin-Qt -rescan

fixed the missing transaction.


Bitcoin offline transaction Consider the following scenario:

create an entire bitcoin raw transaction while offline (no access to the blockchain)
only when you decided to broadcast it that you would need to get online

Is it possible to do such offline transaction? Exactly what fields you need from the blockchain in order to build such raw transaction?

Not in a user-friendly way, no.
Simple version
Your offline Bitcoin client needs more information to identify which coins it is spending, so there needs to be some communication from the online computer to the offline computer. Typically, this is done by preparing most of the transaction on the online computer, then transferring it flash drive to the offline computer to be signed.
Technical version
You need the outpoint, scriptPubKey, and amount of each input you want to spend. The outpoint is composed of the 256 bit hash of the transaction that sent you the Bitcoins, and a small integer showing which output of that transaction you're spending. You also need the scriptPubKey to tell you which key you need to use to sign the transaction. You need to know the amount so that you can specify the correct amount of change to send back to yourself. (Otherwise, the unspent money will just go to the miner.) This requires about 61 bytes of space per input. If a single input doesn't have enough to cover the transaction, you'll need to combine multiple inputs.
You could definitely ask the user to manually transcribe/renter this information, but I think that's asking for a mistake.


If there was an easy way to check for double spends, will consensus algorithms be needed? Currently, checking for double spends is very computationally expensive, so consensus algorithms, like POW, were put in place to more easily prevent double spends among other things.
Ignoring the fact that a consensus algorithms allows for other essential things to be done, like making sure that new cryptocurrency can only be mined at a fixed rate; if there was a way to very efficiently detect double spends in an incoming blockchain and the protocol was changed so it will reject a blockchain that has double spends and it will accept accept a blockchain with no detected double spends, then will there be no need for consensus algorithms?

Yes, if you assume that the central challenge of a distributed system in an antagonistic environment doesn't exist, hypothetically creating such a distributed system is indeed much easier!

Currently, checking for double spends is very computationally expensive[…]

Detecting doublespends is trivial. You just need to recognize that two transactions are in conflict because they spend the same funds.
The actual challenge of the doublespending problem is to get a network of equal peers to converge on one canonical transaction order. In fact, Bitcoin's most notable achievement is to propose a practical solution to the doublespending problem.

the protocol was changed so it will reject a blockchain that has double spends and it will accept accept a blockchain with no detected double spends, then will there be no need for consensus algorithms?

So, sure, if you assume that there unexplainedly is already consensus on how to solve the principal problem of operating a decentralized currency system, you no longer need to figure out how to achieve consensus. However, that's not a particularly useful starting point.


In NXT monetary system, how do you transfer the coins complete control to another account? I purchased a few MS (monetary system) coins and i want to move it to another account completely. I want that other account to also be able to reissue this coin with new settings too. How can this be done?

The only way is to delete the coin in the old account using the API and for that you must possess all the coins. Then, create the coin in the new account.


Bitcoin scripts that force disclosure of the private key Context: I am creating an example code that would demonstrate an atomic swap between Elements and Bitcoin, with the aim that the swap transactions cannot be trivially linked, as it would be with simple HTLC, where you can look for the same hash/preimage in both chains. This is because the key to disclose is actually a sum of keys, (A+B), and to claim the other side of the swap, another sum key, (A+C) is used. A, B, and C are only known to (one or both) participants.

I use CHECKSIGFROMSTACK on Elements side to force the counterparty to create a signature with fixed R value (the k would be known, and thus the other party can recover the key)

I was pointed to https://bitcointalk.org/index.php?topic=321228.msg13072047#msg13072047, where gmaxwell tells that you can achieve the same effect of forcing privkey disclosure on unmodified Bitcoin.

He says that he is aware of two ways to achieve this on unmodified Bitcoin, one of them is:

OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY

My questions:

in the script listed above, the signature is forced to be of the length less than or equal 57. This seems to rely on known small R value, and assumption that other R values of equal or smaller size for some known k is not computationally possible to find.

in this post https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow an R value with 90 leading zero bits is given. S would need to be <= 29 bytes in size with R length of 21 bytes (166 bit), for signature to fit into 57 byte limit (29+21+6+1=57). To satisfy this script using this known small R, the creator of the signature would need to search for the message to sign that would result in a signature with len(S) <= 29. Is this tight limit chosen to reduce 'wiggle room' for bruteforcing R ?
What is the second method to achieve this on unmodified Bitcoin ?
If these methods work, why they have not been widely used instead of HTLC constructs, given that these methods (or at least the presented one) are not much more complex implementation-wise, but are more private (because there is no public shared hash/preimage) ? What are the downsides of these methods, versus HTLC ?

(Note: The questions above are more out of intellectual curiosity  than for concrete practical purpose, because when Schnorr signatures will be enabled on Bitcoin (I hope that won't be too long), adaptor signatures https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md would be much better way to create atomic swaps without trivial link between transactions)

I've done some searches and research, and I also got input on #elements channel on bitcoincore slack, so I feel that I can answer these now (EDIT: At first I got confused about CODESEPARATOR method, but after some more time, I asked Anthony Towns and he provided the links to his messages in lighting-dev list explaining it.)

I think that the size 57 is chosen for increased guarantee against the possibility that other small-size R value would be found, that is larger than 21 bytes, but small enough that grinding for smaller S could enable to overcome the size limit. I've also seen other example of how this technique might be used (https://gist.github.com/nothingmuch/683042343c48a4ef07efd3d438e7ee56), but it sets 60 for the size limit. It might be assuming that R value that starts with 72 zero bits is not feasible to be found either. It also may be that 57 byte limit is unnecessary small. Note that grinding for len(S) <= 29 is feasible on general-purpose computer. This could be done by changing other inputs/outputs of the transaction so that sighash changes. Relevant: https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
The second way to achieve this on unmodified bitcoin may somehow involve the use of OP_CODESEPARATOR. There would be two signatures of one pubkey, but the second signature would use different sighash because this signature is checked after CODESEPARATOR is executed, and sighash will be calculated using only the part of the script after CODESEPARATOR. But while you can have two different signatures (on different messages) for one pubkey, it is not clear to me how to force nonce reuse here, if not with the same size-trick as described before, or using the disabled opcodes.

EDIT: Asked Anthony Towns about this, got reply. There is a tecnique using two codeseparators and three checkmultisigs, in such a way that forces reuse of R. See https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html and https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000363.html

Other relevant links: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016594.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016592.html My experimental scripts: https://gist.github.com/dgpv/7818a4009f4e90868c0920cc1e238653

Note that CODESEPARATOR is non-standard for non-segwit inputs in Bitcoin, but should be OK for segwit inputs. But still not without some controvesy: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016732.html (there was a proposal to remove CODESEPARATOR altogether, or to calculate sighash always using initial script, disregarding effects of CODESEPARATOR)
HTLC is simpler to implement, and the program that creates HTLCs does not need to be able to work with bignums, along with having the function that implements modular inverse on bignums. HTLCs would also generally be smaller in size. They are also more 'known' and thus popular.


python-bitcoinrpc: only DEBUG available? I'm starting with python-bitcoinrpc from J.Garzik.

I'm using to try it the code provided by James D'Angelo (from Bitcoin 101 on youtube):

Apparently, there were some major changes with python-bitcoinrpc, not taken into account by old tutorial as the ones from James since you don't do now:

from bitcoinrpc.util import *
from bitcoinrpc.exceptions import *
from bitcoinrpc.__init__ import *
from bitcoinrpc.config import *
from bitcoinrpc.proxy import *
from bitcoinrpc.data import *
from bitcoinrpc.connection import *

bitcoin = connect_to_local()
NEW_ADDRESS = bitcoin.getnewaddress()
print(NEW_ADDRESS)

But now:

from bitcoinrpc.authproxy import AuthServiceProxy

access = AuthServiceProxy()
info = access.getinfo() # Not WORKING: info is None

That's okay for me, and very shorter.

The problem is to get access.getinfo()to a variable? According to the README from python-bitcoinrpc, you can use the logging module to print stderr to the screen

logging.basicConfig()
logging.getLogger("BitcoinRPC").setLevel(logging.DEBUG)

rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))
print(rpc_connection.getinfo())

But how do you put that into a variable??
Like with:

info = access.getinfo()
(which is not working: infois None

Okay, there's a bug in the pip version of python-bitcoinrpc...

use pip install git+https://github.com/jgarzik/python-bitcoinrpc.git instead.


Is the time a transaction was done recorded in the block chain? Is there something like a timestamp of each transaction recorded in the block chain, or only the mere fact that the transaction was done?

There's a unix timestamp in the block message. https://en.bitcoin.it/wiki/Protocol_specification#block

So you would be able to get know the transaction hit the blockchain down to roughly a 10 minute resolution.


Missing Deposit in my bitcoin core account I downloaded Bitcoin core to my computer and after that I bought some bitcoins. I didn't realized that my bitcoin core was not synced, after 3 days waiting to finish now my deposit is not showing in my wallet. What can I do?

Depends on which wallet you 'bought' the coins. If it was a paper wallet/ mobile app wallet/ some other wallet software, then obviously it won't come up in the Bitcoin core wallet software. Just FYI, Bitcoin core comes coupled with a lot of other utilities apart from making you machine act as a full node. It has a built in wallet whose balance and other details are accessible via the command line interface, bitcoin-cli or the GUI bitcoin-qt.

Assuming you did not use the Bitcoin core wallet, you need to first import the private and public keys to get the balance. You can go through the API documentation of the bitcoin core. The following links might be useful

Import address

Import private key

Import wallet


Has the BitLicense affected other U.S. state regulators' actions? What aspects of New York's new BitLicense have most affected New York-based companies already?

How have California and other states who are planning BTC policy learned from New York's example? (For example, have other states commented in public on the BitLicense?)

To answer your first question, @Cointelegraph writes "burdensome and expensive process of acquiring such a license, the lack of agility as a consequence of the regulations, or customers' privacy concerns".

Companies who have left New York state because of the BitLicense include, amongst others: ShapeShift, BitFinex, Kraken, LocalBitcoins,Rebit and Genesis Mining.

The blockchain which is used as the underlying transmission component for bitcoin is modeled on the notion of a deregulated system. Attempts by players to regulate a deregulated market demonstrate inadequate understanding of the blockchain technology, while failing to acknowledge the fundamental human right of free market participation by free people.


Could a mining pool attack Satoshi Dice? Is it possibile for a mining pool to attack Satoshi Dice? A strategy might be: bet on Satoshi Dice and if the bet wins, do nothing, if it looses, don't put the transaction in the block (try to double spend) and hope, that the pool find the block. If the hash rate of the pool is big enough this should beat the house edge of Satoshi? Did I miss something?

You're absolutely correct. The following would completely work:

Get ready to perform a Finney attack.
Gamble some coins.
If you lose, go through with the Finney attack. Otherwise, cancel your Finney attack, and collect your 1250 BTC from satoshidice.

Is anybody doing this? I don't know.


Options to automatically invest to Bitcoins each month in EUR? I am looking for options to have automatic transactions to buy bitcoins each month. Trading currency I need is Euro.

What are options to invest each month to buy bitcoins?

localbitcoins - cheap - spread cost min 2.5 % + 1 % (transaction fee) but more time and your work. Big market.
Bitpay (used by Airbaltic company) - easy, but more expensive.

Waiting for better decentralized bt systems still. Etc K.im coming.

Code https://money.stackexchange.com/a/20277/1627


When does a miner exactly start to create a block? As far as I know, a miner begins creating a new block as soon as it receives a valid block from another miner. It then begins to construct and hash the next block on top of the block it just received.

However, in case of existence of orphan blocks, I suppose it starts mining after processing orphan blocks, right? Can anyone tell when exactly a miner would start working on a new block?

A stale block (also often confusingly referred to as 'orphan block') occurs when two competing blocks were found and then another block builds on top of one of them.

See the following minimal example: the blocks B1 and B2 were discovered at the same time and then the discovery of block C clarifies that B2 is part of the chain with the most difficulty ("longest chain"). At this point B1 becomes obsolete, as it is not part of the best chain.

      B1
A ->
      B2 -> C

So, a miner would have received block A, then started to work on finding a successor to that. When B1 and B2 appeared, he would have received one of them first and started building on top of it, ignoring the other as not part of its best chain. When C appeared, the miners that were trying to build on top of B1 reorganize to B2 -> C and start building on C.

At no point would you process a stale block because once it is clear that the block is stale, it must already be part of an alternative chaintip that is not the longest chain. —  There is no reason for you to be interested in it anymore. Especially, there is no reason to start mining on top of a stale block, as you'd be wasting your mining power trying to extend a stale branch of the blockchain (unless you're trying some sort of majority or selfish mining attack).

Actual orphan blocks, i.e. blocks where you're missing the parent block, should not occur by accident on the network as the miner that discovered the last block would be interested in spreading the parent block in order to collect the reward. However, when the parent becomes known, it's not an orphan block anymore. ;)

On the other hand, if a block is not connected to the blockchain at all, it's simply going to be treated as an invalid block by all other network participants.


What happens when relative and absolute lock times are used in the same transaction? BIP 68 redefines the input sequence number field as bit vector that encodes a relative lock time.

A transaction can be encumbered with an absolute lock time by setting the nLockTime field to a non-zero value and by ensuring that at least one input sequence is non-maximal (not 0xffffffff).

What happens if a one-input transaction sets nLockTime > 0 and introduces a relative lock time under BIP 68? For example, nLockTime might expire in 12,000 blocks and the input's relative lock time might expire in 11,000 blocks. Conversely, the relative lock time might expire after the absolute lock time.

Which locking mechanism wins in these cases? Are both locks checked, or only one? If the latter, which one?

The "Compatibility" section of BIP 68 hints that both locks will be checked, but from my reading doesn't state this explicitly:

  The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.

When a specific locktime is specified in the nLockTime field in a transaction. It means that said transaction cannot be broadcasted/be accepted by miners until either the blockheight or unixtime has elapsed.

On the other hand, when a OP_CSV is used, it means that a transaction referencing said input cannot be spent until some blockheight or unixtime has elapsed.

If we merge both and use them together, basically, we will create a transaction that cannot be broadcasted to the Bitcoin network until some nLockTime has elapsed and it also cannot be spent until some blockheight or duration of time has elasped. OP_CSV specifically targets the spendability of a transaction, whereas a time-locked transaction simply prevents some transaction being broadcasted to the Bitcoin network until its locktime has elapsed.


Bitcoin transactions between two parties Lets say bitcoin become a global currency which replace fiat money..
If someone (physically )is asking for bitcoins and its urgent and i don't  have phone to access the network and the one whos asking don't  have the phone also.how can this transaction be done.because with fiat money you could just take the money out of your pocket and give him

Lets say bitcoin become a global currency which replace fiat money

Logically, if Bitcoin were to fully replace fiat money and be used for every transaction, then we should expect there would be some way of facilitating transactions easily, in pretty much every situation. Otherwise, people aren't going to adopt it if it is a worse solution that what is already available.

But to answer your question more directly: there are ways to transfer ownership of provably not-backed-up private keys, such as the OpenDime (disclaimer: I have never used an OpenDime, but understand how they are supposed to work, in concept). So if you had a device like the OpenDime that was loaded with the correct amount of BTC, you could just trade it to your counterparty. No internet connection needed.


Bitcoin address security I understand bitcoin addresses are randomly selected from such a large pool that the statistical chances of someone discovering your address is very low.

In light of the above is it still not possible?

i.e. if I have a large holding of bitcoin in an address the someone "could" by chance generate the same private key and access my fund.

Is this correct?

Technically, yes.
Realistically, no.

As long as your private key is random, you should be fine.

Still concerned? Maybe you want to consider multisig, as it would require M of N keys to collide, making the already practically impossible, even more impossible.


What is the difference from coinjoin and a coinshuffle transaction? Coinjoin and coinshuffle creates an anonymous transaction. But how are they different? And which services implemented these features?

CoinJoin is the core idea underlying CoinShuffle (and other mixing techniques).

The idea behind CoinJoin: "When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together". This leaves out two major details:

How two (or more) participants who want to make a payment find each other?
How is the joint transaction composed and submitted to the network?

This leaves much room for different approaches and implementations. There's more info about some of them here.

CoinShuffle only addresses the second question.  When you think about this problem for a moment, the obvious solutions which come to mind involve a centralized entity to compose: either a 3rd party, or one of the participants. It isn't immediately clear how this can be done in a decentralized manner, which also protects their privacy.

CoinShuffle describes an elegant decentralized protocol for constructuring the joint transaction in such a way that no privacy is compromised: there is no "centralized coordinator", and even the participants cannot link inputs to outputs (except for their own input and output, of course, which they chose). Of course, this unlinkability feature only makes sense if there are more than two participants.  The protocol is elegant and simple, and is described here.

Also, I don't think it is accurate to say they "create an anonymous transaction". It is more accurate to say they create a joint transaction in which it is either hard or impossible (depending on the method used and some implementation details) to link inputs to outputs, thus (among other things) improving users' unlinkability and making taint analysis harder.


Why is it safer to keep your bitcoins offline than online on Coinbase? I'm trying to think of a good way to store my bitcoins somewhere but I can't really think of a way to do it without

1) having something physical (eg. USB key) that can get lost or destroyed
2) having some sort of password (that I can forget)

The problems with either of those things is I'm planning on leaving my bitcoins to sit for a long time so by the time I need to sell them, I may not be able to remember all the details.

I was thinking maybe I should just leave my coins on Coinbase. At first that sounds more risky giving my coins for somebody else to manage, especially given what happened to Mt Gox.

However, whilst cryptocurrency is kind of like the wild west, Coinbase is a legitimate company. They're also fully insured so if they do get hacked, it doesn't sound like I would be on the hook for any loss. In addition, accessing the coins requires two factor authentication and furthermore, they have my identification details. So these features protect me against me losing access to my own coins.

So please explain why it is safer to keep my own coins offline where I would have to manage and implement my own security instead of just keeping it on CoinBase where they have professionally implemented security, contingencies for if I lose my credentials and where my coins are fully insured?

Let's assume you keep your bitcoins on the exchange for 5 years. If the company behind the online wallet goes bankrupt, is hacked, or is malicious, you lose your bitcoins. If you kept them on a hardware wallet and kept the mnemonics in another, safe location, you can still recover them in case of fire, disaster, turmoil.

Mt.Gox taught us that trusting in another's private keys for your holdings is not a good idea. Many of the people who lost hard in that episode are still waiting for a reimbursement.


Bitcoin sent, recipient claiming not received I sent bitcoins to the address I was given (double checked). The recipient is claiming they did not receive it. I sent them a different payment yesterday at 8:30p and they didn't get it until 4:00am so could there be a lag also with this payment? Or are they lying? Please see below for btc address. I sent it this morning at 8:30am.

1LGSCBLrrX8pBehwRxUvZU29UAmVAX6jjZ.

The address received 0.07014343 BTC in 3d727e3f4565e011c0348f813c2d5480210b6bae2003a0f7abaa949d1a7c599a. These coins have already been spent, so at the very least the recipient's wallet provider is aware of the transaction. Depending on the type of wallet, the recipient's account may not have been credited due to internal system issues.

Alternatively, the recipient has received the funds and is trying to scam you for an additional payment.

In either case, your initial transaction is successful, and the recipient needs to work with their wallet provider. You should not send them any more funds.

Checking if a transaction is complete

Due to the attention this question is receiving, I'll go through some of the best practices when checking the finality/completion/status of a transaction.

For a Bitcoin transaction to be complete and irreversible, it must be mined into a block.

To check if a transaction has been mined, you can check a block explorer. Block explorers are websites that read information from the blockchain and make it accessible to people who are not running their own node. Some commonly used explorers for Bitcoin are blockchain.com, blockchair.com, blockstream.info, and btc.com (no affiliation to any of these).

When you look up the transaction, such as with the link above, you're presented either with a page detailing the transaction, or some form of a not found error.

If a transaction is not found, it has almost certainly not been mined - in this case, you should aim to rebroadcast the transaction instead of sending a new one. It is possible that the transaction has actually been broadcast and just not picked up by the explorer yet, so sending a second one may result in a double payment.

If a transaction is found, it may be listed as unconfirmed. In this case, just wait until it is confirmed. If a transaction is already confirmed, you should see some indication of the block it was mined into (either in the form of a block number, or a block hash starting with a bunch of 0s). If a transaction is confirmed, then it is complete and irreversible.

The recipient says they didn't receive the coins

There are a handful of scenarios in which the recipient may not see the coins even after the transaction is complete:

The recipient's wallet is out of sync/not updating correctly - this is a more common scenario when using exchange or other hosted wallets, or using a regular wallet with a spotty or weak internet connection. In this case, the recipient must check with their wallet provider to locate and credit the coins.
The address is incorrect - Either you made an error while copying the address, or the recipient provided an incorrect address. In this case, you should work with the recipient to figure out who needs to absorb the loss as the coins are most likely irrecoverable.
The recipient is attempting to scam you - once a transaction is complete, only the recipient can access, locate, or otherwise try to work with the coins. If they insist they haven't received them, it is not due to an issue on your side, and you may be getting scammed.

Things to note

Do not use an explorer recommended to you by the recipient - it is trivial to build an explorer that hides certain transactions and makes you believe they are not complete when they are. Always use multiple third party explorers if you must. Ideally, you should run your own instance of Bitcoin Core with -txindex enabled and check the transaction yourself, but that is not feasible for many users on short notice.
If you really do need to resend the coins, first make a transaction to your own wallet that sends the entire balance to yourself and wait for that to confirm. This prevents you from accidentally paying twice if the initial transaction was simply not broadcast properly.
Be patient - transactions with low fees can take a couple of days to confirm during high network activity periods - if you see an unconfirmed transaction, just wait.


How to log sizes of each block I am looking to do some research on the blockchain, is there anyway to easily the size of each block while i download it - i have seen graphs from coinbase etc, but these are not accurate for me as for the first 12 months they put the blockchain size as 0MB - Any ideas welcome, i have looked through the log file of bitcoin during the download and while it gives me data about the number of tx in the block etc it doesn't contain the size

What you can do it traverse back from the chain tip via RPC:

call getbestblockhash (RPC)
Use blockhash to call getblock (RPC)
Read size -> store it somewhere (CSV file, etc.)
Read previousblockhash and use it as blockhash for getblock
Goto step 2


Would sidechains help Bitcoin scale? Are sidechains intended to help Bitcoin scale? Do they reduce load on Bitcoin's main chain?

If not, why not?

No. They can increase scale, but that is not what they are good at or intended for.

Before giving a longer answer, let me first talk briefly about the difference between scale and scalability.

Increasing scale means increasing the throughput or number of participants to the system. It's very easy to achieve (decreasing the time between blocks, or increasing the size of blocks), but it would come at a cost of higher centralization pressure for mining and increased validation cost to the system. Whether these increased costs are acceptable is controversial, but there are certainly costs involved.

Increasing scalability means changing the system in a way such that increased scale comes with less increased costs. Known mechanisms for better scalability include better peer to peer relay protocols, faster digital signature systems, software improvements, technology on top such as payment channels or lightning to reduce on-chain transaction need, ...

Sidechains don't improve scalability. If we want the same security level with sidechains, the same amount of people and miners need to be validating them. That is at least as costly as just increasing the block size of Bitcoin itself, and sidechains come with extra compromises on top of that.

So, sidechains may increase scale, but are not better at it than larger blocks would be.

What sidechains do bring is the ability to experiment. To be able to build networks that run on different - and possibly better-scaling - technology, but without needing to first beat bitcoin's (the currency's) network effect.

Sidechains are intended to improve scalability, but only indirectly: by enabling innovation. Not because they can just offload things from Bitcoin.


How does bitcoind generate a new address if the wallet is encrypted Suppose that my wallet is encrypted with a passphase and currently I have not provided bitcoind with the passphrase to access the private keys section of the wallet.

If I enter:

bitcoind getnewaddress

It prints a new address, say [someaddress], but where does it store the private key that goes with it?

If I enter:

bitcoind dumpprivkey [someaddress]

I get an error message since I have not provided the wallet passphrase.

But if I first provide the wallet passphrase and then try dumpprivkey it shows the private key.

When I asked it to get a new address, I had not provided the passphrase, so how it store the private key?

It gets it from the keypool, which has 100 pre-generated addresses by default.  The next time you enter your passphrase, it will refill the pool with new addresses.

Here's an example that shows the pool running out, and refilling when the password is supplied.  The following commands were performed by a trained professional.  Please don't try this at home (especially the first 2 commands):

$ cd ~/.bitcoin
$ rm wallet.dat
$ bitcoin-cli -daemon -keypool=5
bitcoin server starting
$ bitcoin-cli encryptwallet mypass
wallet encrypted; bitcoin server stopping, restart to run with encrypted wallet
$ bitcoin-cli -daemon -keypool=5
bitcoin server starting
$ bitcoin-cli getnewaddress
1Bf6TrgiBxzZhdtEWZuWuREkbfoAtmZ5xa
$ bitcoin-cli getnewaddress
1JzjmeH1LHzJ5JYzUu3wh36N7LWvfVeB2u
$ bitcoin-cli getnewaddress
1sjVdVJAAWB6JTsja4nEVezdnqiE6Ko3V
$ bitcoin-cli walletpassphrase mypass 3600
$ bitcoin-cli walletlock
$ bitcoin-cli getnewaddress
1DVZHRNbdBivqRKzas7iFT8emsb8EtcJT1
$ bitcoin-cli getnewaddress
1HBXkVkWCVhntzgkxdb9hnUxNeMdFqVssQ
$ bitcoin-cli getnewaddress
18n17UHshaufcufo5z1PBPAdErPWxesBhs
$ bitcoin-cli getnewaddress
1CofrGkqWrAmibBUgtLysknXdsBpDJARTs
$ bitcoin-cli getnewaddress
1NwWuba3khc31ebZU8fVAept2MDdnSndgV
$ bitcoin-cli getnewaddress
16QVdikDatH2FkQNkrRgGXrQ9LbEooHAPF
$ bitcoin-cli getnewaddress
error: {"code":-12,"message":"Error: Keypool ran out, please call keypoolrefill first"}
$ bitcoin-cli walletpassphrase mypass 3600
$ bitcoin-cli walletlock
$ bitcoin-cli getnewaddress
1BSDX4PiHKvdssjAzDLVACAAQvwiijmETV
$ bitcoin-cli getnewaddress
1JJphgnC5gqunLtbbLAwtN8LXRnCUYWARm
$ bitcoin-cli getnewaddress
17UJqrpuakgPPuxPTLa8LeeWVAKijZW66x
$ bitcoin-cli getnewaddress
16itq5LpuwyhtfbiHbQxVzJYYdGE7nQRoz
$ bitcoin-cli getnewaddress
1QA4EnXPUHquK9WBxBppicfBTD2gYTB9ic
$ bitcoin-cli getnewaddress
12bgaABsakRouK9NZyUAK1RAD9nmDtHQKa
$ bitcoin-cli getnewaddress
error: {"code":-12,"message":"Error: Keypool ran out, please call keypoolrefill first"}
$


A full/multi nonce range search or just a partial range search? In a work, there are only two elements in the block header change between hash attempts. That is, NTime and Nonce. The miner starts the nonce search to get a valid share, and there are several possibilities:

1) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, so the miner exits the nonce search for this work and submit the nonce instantly, and then get another work from the pool.

2) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, then the miner record it, and go on the nonce search until the complete of the nonce range search, and after this full range search the miner submit the recorded nonces  and get another work from the pool.

3) The miner can't find a valid nonce after a full nonce range attempts, so it performs NTime rolling, and then start a new nonce range search, and also there are also some possibilities just like the above statements for the miner to finish this work and get another work from the pool.

Actually, my question implies another question, for a fixed work(except for the nonce), is it possible that more than one nonce can be found to get a valid diff 1 share?

1) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, so the miner exits the nonce search for this work and submit the nonce instantly, and then get another work from the pool.

It doesn't, because the fact that you found a valid share doesn't mean that there's not another nonce that creates a share.

  Actually, my question implies another question, for a fixed work(except for the nonce), is it possible that more than one nonce can be found to get a valid diff 1 share?

Between 0 and 2^32 shares/blocks will be found for every nonce range.


How can I analyze the test coverage of the Bitcoin Core codebase? I have heard writing tests is a good starting point for contributing to Bitcoin Core. How do I work out which parts or specific lines of the codebase need additional test coverage?

Marco Falke has a site that analyzes the current line, function and branch coverage for unit tests, functional tests and fuzz tests.
Alternatively, vasild runs clang's tools and then a script to highlight which lines in the coverage report have been modified by a particular patch (PR).


Is Bitcoin network truly distributed without central authority? When a node joins the Bitcoin network it gets its info from either a preinstalled list, dns or irc. All of these 3 could potentially imply a central authority for who's on the network. Who exactly maintains them?

You can get your pre-installed lists from anyone you choose by any method you choose. There is absolutely no requirement to you get these lists in any particular way or from any particular authority.

If you wish, you can make your own list of bitcoin nodes you consider "valid". You can publish this list by a web page, by DNS, or by any other method you choose. Anyone who wants to can use your list, or not use your list, however they want. And Bitcoin will work just the same.

When someone follows an "authority" because that authority is convenient, I do not consider that centralization. As long as people are free to choose to follow a different authority, or just do it themselves, if at any time they no longer like what that authority is doing, that's not centralization in my view.

And, of course, none of this is relevant once you find a few bitcoin nodes to talk to. It only affects the initial bootstrapping process. You have the same issue with getting the bitcoin software in the first place. Is bitcoin not decentralized unless everyone writes their own implementation of the protocol? Or is it decentralized so long as people are free to if they wish?


How can a share be 'harder' I am on a pool that asks you to select a difficulty for your miner. How can some shares be harder than others if they are just a hash?

The lower the hash has to be, the higher the difficulty. Finding a hash whose first 32 bits are zeroes is not as hard as finding a hash whose first 36 bits are zero.

If you have a relatively slow miner, you probably don't want your shares to be too difficult or you'll find them only rarely and the accuracy of your tracking will be poor. But if you have a very fast miner, you probably don't want your shares to be too easy or you'll be finding so many of them that reporting them to the pool can become a bottleneck.