What is the math behind a private key BASE58 (P2PKH) Using this link I can understand something about a private key BASE58 (P2PKH):
"such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'."
So let's say I have this model of private key:
5J1111111111111111111111111111111111110111111222222
I know that is not a valid private key because I can use a website such as bitaddress to tell me about this.
Taking a private key like this, I would like to understand how I can verify if it is valid, what the procedures are, because I would like to write a script to play around with this.
Keep in mind I don't have any other information, just a string like that.

Taking a private key like this, I would like to understand how I can verify if it is valid, what the procedures are, because I would like to write a script to play around with this.

Check if the string has valid Base-58 characters (123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz)
Decode the string to get the byte array using Base-58 encoding while removing and validating its checksum (last 4 bytes). Refer to the wiki link you posted for details.
Take the first byte and check if it is using the expected (version) value (128 for MainNet, 239 for TestNet).
Check the remaining data length (without first byte):
4.1. If it is 32 bytes, that is the key
4.2. If it is 33 bytes, remove last byte and check if it is equal to 1, the rest is the key
4.3. If the length is anything else, it is invalid
Convert the 32 bytes you have from step 4 to a 256-bit integer using big-endian definition
The value of step 5 has to be >= 1 and <= 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140


Does bitcoin deflate or does it appreciate? How are these two terms related?

Bit Coin is obviously appreciating in value, but does that alone mean that the economy is deflationary? Or, is deflation and inflation a result of external pressures and not just the perceived value of the commodity?

Since bitcoin is appreciating, the amount needed to buy the same stuff will be less in the future. That makes the economy around bitcoin deflationary.


I generated a Signet address on a Bitcoin Core PR branch and obtained some Signet from the faucet. How can I locate that private key? I previously (months ago) generated a Signet address on a Bitcoin Core PR branch and obtained some Signet from the faucet to that address. How can I locate that private key in my file system if I know the Bitcoin address? How can I locate that private key if I have forgotten the Bitcoin address?

As Pieter says in the comment the private key is in the wallet.dat file and you can use:
./src/bitcoin-cli -signet dumpprivkey insert_signet_address
to get the private key for that signet address.
There are separate wallet.dat files for each chain (mainnet, testnet, signet, regtest) that persist across the different PR branches and different versions of Bitcoin Core you run. These aren't ever replaced or written over. If you have signet Bitcoin on one PR branch, then you build and run another PR branch you will still have access to that same signet Bitcoin that you had on the previous branch in the usual way.
Pieter added below:

Every chain has its own distinct default datadir, and everything in
that datadir (including blocks, chainstate, peers.dat, onion
addresses/keys, ban data, fee estimates, mempool dumps, ...) is shared
between all codebases that use that chain.


running live and test node simultaneously it took me 4 days to fully synchronize my node, but its finally running and i can create wallets etc..

I wanted to experiment with some transactions on testnet, so need to either change my config or create a separate instance.

But I don't want to lose my synchronized live node, so what's the best strategy to switch to testnet while still being able to switch back?

# [core]
datadir=/mnt/volume-nyc1-03/Bitcoin
dbcache=2000
txindex=1

# [rpc]
# Accept command line and JSON-RPC commands.
server=1
# Username for JSON-RPC connections
rpcuser=bitcoin
# Password for JSON-RPC connections
rpcpassword=sayblockchainonemoretime
rpcport=8332
rpcallowip=x.x.x.x/x (ip masked)
# [wallet]
# Do not load the wallet and disable wallet RPC calls.
disablewallet=0

You can run both at the same time:

$ bitcoind -daemon
$ bitcoind -testnet -daemon

Then you can issue commands on either using:

$ bitcoin-cli <commmand>

or

$ bitcoin-cli -testnet <command>

The blockchains are stored in ./bitcoin/blocks for mainnet and /bitcoin/testnet3/blocks for testnet.

Update: With the bitcoin.conf updated in the question remove rpcport=8332, so it doesn't try to use the same port for mainnet and testnet RPC.

Update 2: With 0.17 release, it is now possible for a single configuration file to set different options for different networks in bitcoin.conf:

main.uacomment=bitcoin
test.uacomment=bitcoin-testnet
regtest.uacomment=regtest

For more information, see the 0.17.0 Release Notes


How do I make a profit buying cloud-hashing contracts? I have tried one of the hashpower selling/buying website (nicehash) to buy hashpower. I have connected my order to a pool where I had one worker.
However, despite all the advertisements, I could not make a profit! I do not know what to watch to know whether my order is profitable or not?

And what makes the profit at all? Is it the fact that the hashpower I buy will become more hashpower if I mine in a pool (I observed that sometimes that is the case, but not for the whole lifetime of the order)?

Thank you!

I use this analogy for cloud mining:

  If you had a money printing machine would you rent it out or use it yourself?

Cloud mining -no matter how you consider it- makes no sense financially. If the company is making a loss, they'll be out of business, if they're making a profit, why aren't they making that profit directly?


Why is no security lost by using 32-byte public keys in Schnorr signatures instead of 33? There is currently a discussion on the mailing list about truncating the 33rd byte from public keys when used in bip-schnorr.

Public keys are (x, y) coordinates and compressed public keys simply replace the y coordinate with a single byte indicating its oddness. The complete y coordinate can then be derived from the given x coordinate, and so the public key can be expressed in just 33 bytes instead of 64.

By removing the "oddness" byte, public keys will only be expressed by the x coordinate, meaning there are two potential points on the curve that could be represented. This also implies that the same single x-coordinate-only public key could actually be derived from two different private keys.

My question is, why does this not affect the security assumptions of the Schnorr signature? Is it just a subtle effect, like replacing 256 bit security with 255 bit security?

From the (very recently updated) bip-schnorr draft:

  Implicit Y coordinates are not a reduction in security when expressed as the number of elliptic curve operations an attacker is expected to perform to compute the secret key. An attacker can normalize any given public key to a point whose Y coordinate is a quadratic residue by negating the point if necessary. This is just a subtraction of field elements and not an elliptic curve operation.

The idea is that if somehow using implicit Y coordinates was less secure, then an attacker would always use it - even in a the protocol version that has explicit Y coordinates. The attacker would take the full public key, strip the Y coordinate, run his (presumably faster) implicit-Y ECDLP solver on it to find the private key, and if the actual point corresponding to that key is the opposite of what he wants, flip the private key.

This proves that the ECDLP problem's hardness cannot meaningfully be impacted by removing the Y coordinates.


If I have a join shared wallet and my partner lost the backup, can we recover this if i can i see the BTC yet? I had a Join Shared Wallet. I can see my BTC; but my partner can´t because she lost the back up words. We aere trying to send this to an other wallet but it´s imposible if the other account doesn´t authorized it. What can I do for recovering these wallet?

Assuming this is a 2-of-2 multisig shared wallet, it is not possible to do anything with the coins without signatures from both wallets.  Bitcoin uses strong crytography, and when signatures are required, they're really, really required.  That's why it's secure.

If your partner has irretrievably lost the wallet and backup phrase, then the two of you have irretrievably lost the coins.  Sure, you can see them, but you'll never be able to spend or transfer them.

Sorry.


What is "version" used for in Bitcoin transactions? Does it have any meaning? Some bitcoin transaction have version 2. For example, this transaction

https://blockchain.info/tx/b7022124bc7f31af9342d2f7af98ad9f60f2fd4fa544bf1affca8a436aadda41

if you request a hex (by adding ?format=hex for example) and putting it into https://blockchain.info/decode-tx , you get "version":2.

What does this mean? There are more transactions with version 2 out in the wild, but not that many.

In zcash transactions, version 2 means that the transaction has joinsplits. But I cannot find what it means in bitcoin.

I have found examples of version 2 transactions here and here

It seems to be related to BIP 0068.

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

BIP 68 deals with relative locktime and repurposes sequence number for a that purpose. Relative locktime allows the user to set locktime relative to a previous output.

As of April 2017, Shapeshift uses only v2 transactions, when exchanging from altcoins into bitcoin.

Just for interest, zcash says this about version 2 (zcash uses version 2 to mark transaction with "secret" inputs/outputs):

  Note: A transaction version number of 2 does not have the same meaning as in Bitcoin, where it is associated
  with support for OP CHECKSEQUENCEVERIFY as specified in [BIP-68]. Zcash was forked from Bitcoin v0.11.2 and does
  not currently support BIP 68, or the related BIPs 9, 112 and 113.


Duplicate ANY transaction from Bitcoin to Bitcoin Cash.. is it possible? After the hard fork happened on 1 August and Bitcoin Cash was created the blockchain diverged in two. Any transaction before 1 August made on the main blockchain now is available on Bitcoin Cash chain.

So my question is:

What will happen if I random pick any transaction from the bitcoin blockchain after 1 August from random block and push it to Bitcoin Cash nodes? Will this transaction get approved?

No, transaction will not be approved. There are differences in transaction format. Transactions are not valid between 2 forks.


Who proposed the XBT ticker for Bitcoin and why is it used over the more logical XBC ticker? Some standard requires tickers for currencies to start with an X. So, the usual abbreviation of Bitcoin, BTC, cannot be used in contexts where this standard is applied.

Usually, the unofficial ticker/abbreviation XBT is used in those contexts. Why? Bitcoin consists of two words, bit and coin, it's logical to abbreviate that to BC. For this reason XBC sounds like a much more logical ticker than XBT.

What is the first reference of XBT and is a consideration made before using it that favoured it above XBC?

XBT is used because the ISO 4217 (the standard for currency codes) alphabetic code XBC is already in use.  It stands for the European Unit of Account.

Here's the Official table of ISO 4217 codes

The X indicates it's not a national currency, but rather a supranational currency (like the East Caribbean Dollar, XCD) or something else that isn't quite a currency, like IMF special drawing rights (XDR) or precious metals (XAU is gold, XAG is silver, etc.) for which exchange rates are of interest.

X is used for this because ISO 3166, the standard for country codes, never uses X as the first letter and the currency code is the 2 letter code and usually the first letter of the currency name.  For example, JP is the code for Japan, so the code for the Yen is JPY.  An exception example is the Mexican Peso, code MXN.  MX is the code for Mexico, and the N stands for New Peso.


MtGox websockets vs HTTP - which is more real-time? MtGox currently offers both a websockets and HTTP API services. According to the documentation the HTTP service caches prices for 10sec but there is no clarification (that I can find) that details the real-time guarantees of the streaming services?

Which would be expected to be closest to real-time?

You would expect websockets to be more real-time because it is designed as an upgrade to HTTP to enable live streaming and real-time services.


Proof of private keys ownership for multiple addresses In a two party coinjoin consists of Mr Seller and Mr Buyer.
Mr Seller has set A of sender addresses/input and set B of receiver addresses (output)
Mr Buyer has set C of sender addresses/input and set D of receiver addresses (Output)
Assume all input/output are addresses (P2PK or P2PKH and none of them are script).
How does Mr Seller prove to others that set A and set B addresses belong to him? Is there any other way to prove than proving the address one by one which can be very long. On top of that set B addresses are hashes.
Mr Seller also need to cooperation from Mr Buyer to provide proof that
set C and Set D address belong to Mr Buyer.
This is a requirement from IRS audit department who wanted proof of payment amount from
the given invoice record.

Why would you prove ownership of inputs/outputs in two-party coinjoin? This data upon publishing would make the coinjoin efforts obsolete and would totally cancel all anonymity set in this specific transaction.
For input you could use some specific wallet setup where inputs would be in separate xpub derivation path, and outputs in separate.
Even with point 2. you'd have to post the outputs as the list of addresses if you don't want to leak pubkeys?

This looks to me like an XY problem and your requirements are contradicting themselves. Could you explain what you're trying to achieve?


Double spend / bitcoin Bots As you all know it's not very secure to send bitcoins on known addresses, some bots are watching.
Could someone explain me how these bots manage to propagate several transactions of the very same transaction output in the network (ex https://blockchain.info/fr/address/1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN)
It appears there is a competition between at least 3 bots on the previous address.

For fun, I try to code a C# app building+broadcasting transaction as soon as bitcoins are received on the watched address. No chance at all. Bitcoind/blockchaininfo says this output is already spent (only 2 s after receiving it). So if there is a mechanism which prevents to add multiple transactions on the same output (before any confirmation), how did current bots do that (1LdUHTEVxWJhrhKfy4H3VuYDnTHQVjsdBn  && 1aa8hSJaxa2jKFtuBYp8VBsFNofsnoBHX)???

And it seems that  1LdUHTEVxWJhrhKfy4H3VuYDnTHQVjsdBn is almost always the winner!

Unless we can see exactly where the bots are operating and exactly how the propagate their transactions, we'll never know exactly how one bot wins over another on addresses where the private key is known. However, we can guess on how they win:

These bots are run by miners. As soon as they get a transaction that outputs to a known address, they immediately create a transaction that spends the output to one of their addresses. If they happen to mine that block, the output is theirs. If not, they can still propagate the transaction and hope to get the output anyway.
The bots run on really well-connected nodes. Multiple bots spending the same output is essentially a double-spend. In a double-spending situation, the better connected and faster propagating will win (in the absence of the above). It's possible someone has direct connections to the most well connected nodes and can propagate such transactions very quickly.

My guess is on #1, though it's hard to say for sure. If it is #2, it's possible it's a well known website like blockchain.info.

Basically, we're speculating, but you, as an independent node without any special relationships to miners or large nodes, stand no chance of winning over either #1 or #2.


Has the BitForce Bitcoin Miner be connected to a PC all the time? When the BitForce Bitcoin Miner is mining, does it have to be connected to a PC all the time?

Yes. Mining devices such as this are merely highly-specialized processors that communicate with a computer via serial over USB. The computer is necessary in order to tell the device what to do, and to get its result to post to the mining system (i.e. a pool or bitcoind).


Is wallet.dat linked to the blockchain file? Just started using Bitcoin today and since I needed them rather urgently, I hastily bought them and transferred them to my wallet before actually setting up my wallet. The client is downloading the blockchain but it’s taking painfully long… 3 hours and counting.

I was just wondering if I downloaded the blockchain from sourceforge without replacing the wallet.dat file will I get the coins I bought and transferred to said wallet?

From what I know, yes. The wallet and the blockchain data exist independently from one another. The wallet file keeps track of all transactions relevant to itself that appeared in the blockchain, as well as information about the latest block it has seen. If you use an old wallet on a newer blockchain, the client should scan any blocks that came after the waller's last synchronisation and update the information accordingly.

If you need Bitcoins urgently, you might want to use an eWallet until your client synchronises. Those are ready to run in seconds.


>50% crash induced by stakeholders of current financial systems This is a though I had a few days ago.

There are stakeholders of our current financial systems who would like to secure their wealth. If these stakeholders sense bitcoin as a threat to their wealth, they would want to stop it. In this case they would want to stop it with a >50% attack.

I have read the Bitcoin Papers and found the following:

  The incentive may help encourage nodes to stay honest. If a greedy attacker is able to
  assemble more CPU power than all the honest nodes, he would have to choose between using it
  to defraud people by stealing back his payments, or using it to generate new coins. He ought to
  find it more profitable to play by the rules, such rules that favour him with more new coins than
  everyone else combined, than to undermine the system and the validity of his own wealth.

Since the current financial systems won't get undermined, a >50% attack still makes sense from their point of view.

How big are the efforts to induce a >51% attack? (DDoS / hack Pools + provide own hashing power)
Could the crashed BlockChain get recovered? (after implementing attack prevention code)

How big are the efforts to induce a >51% attack? (DDoS / hack Pools + provide own hashing power)

I don't think anyone really knows. What you would need to know is how much hashing power, either currently being used to mine or not, is controlled by a single organization that might develop malicious intent.

If a pool, or pools conspiring, suddenly started launching 51% attacks, miners would leave those pools. But by that time, some damage would certainly be done.

  Could the crashed BlockChain get recovered? (after implementing attack prevention code)

Sure. In theory, all the honest Bitcoin users could agree to rewind the blockchain to a point prior to the first significant reorganization. At that point, there would be a battle to get transactions in before others get conflicting transactions in. There would be winners and losers and it would be ugly, but Bitcoin would survive.

It's not clear what the "attack prevention code" would consist of. One possibility would be to change the mining algorithm so that the attacker would have to buy all new ASICs, but so would all Bitcoin miners, so it's not clear whether you could obtain an agreement to do this.

Another possibility is a trusted central authority to issue "mining contracts". Miners would have to sign their blocks and miners who attempted 51% attacks would find their contracts revoked. This would have the unfortunate effect of centralizing Bitcoin somewhat, but at least each pool could decide for themselves which "contracts" they'll honor.

Perhaps there are better solutions out there.


Blockchain.info API - Check transactions from one address to another Using the blockchain.info API, how can I check the transactions from one address to another, including the number of confirmations?

Clarification: I have one address let us say. I want to programmatically check new transactions, without running a wallet and a full node on my computer. So my address is fixed. The sender address is also fixed. So, given 2 addresses, get all the transactions from one to the other. And ideally including the number of confirmations.

You can use pybitcointools history(address). Note that this function has bugs, so try my fork instead.

Or, the API request for 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX would be:

https://blockchain.info/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX?format=json&offset=0

If there's more than 50 results, you'd change offset=50.

I'll provide more details if required.

My personal recommendation would be to use this API call, as there's no offset issues:

https://bitcoin.toshi.io/api/v0/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX/transactions


Why were miners still mining BTC at times when BCH was 2-4x more profitable to mine? From August 2017 until mid November (prior to BCH's hardfork with the difficulty adjustment algorithm) there have been some occasions (notably end of August, beginning of October and mid November prior to HF) where mining BCH was 2-4x more profitable than mining BTC. See: https://bitinfocharts.com/comparison/mining_profitability-btc-bch.html#1y

You would expect that in such cases, where mining one coin compared to the other is much more profitable, all miners would switch to the more profitable coin. However, this did not happen, even when BCH was 4x more profitable, there was still hashrate on the BTC chain (see: https://bitinfocharts.com/comparison/hashrate-btc-bch.html#1y).

What could be a possible explanation for this? I am looking to hear a miner's perspective on this.

Thanks in advance!

Some miners may be ideologically opposed to BCH and thus will not mine it or help it in any way. Others may be too lazy to switch their hash rate to BCH or do not trust any BCH mining pools so they do not switch. Yet others may simply have been unaware of these profitability spikes and were not available to switch their mining hardware to BCH. Given that the change in profitability was only for a very short period of time, some miners may not have had the time in order to switch their hardware, or the effort was not necessarily worth it.

Additionally, mining on BCH means that they would be mining a much less liquid currency. BCH does not have nearly the same trading volume as Bitcoin and mining BCH means that the miners may be stuck with a coin which they do not want and may even lose value compared to what they would earn with Bitcoin.

It is important to note that even if not all miners switch, some still did which you can see in the hashrate charts. This did happen fairly frequently as the EDA could be gamed so that mining on BCH briefly was more profitable than Bitcoin, and several miners did do this.


What is in the Bitcoin Core LevelDB dbcache? Is it full records or metadata? What is in the Bitcoin Core LevelDB dbcache? Is it full records or metadata?
This question was asked on IRC by Anonymous.

The Bitcoin Core documentation describes dbcache as the cache for the UTXO database.
Wikipedia describes a cache as a:

software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere.

Greg Maxwell added on IRC:

There are basically two separate uses: the block index which is
essentially metadata and the UTXO database.
The dbcache is not really a cache, it's a write buffer and it prevents
needing to sync the disk or make random writes. As a cache it doesn't
do much and isn't needed for that. It does also act as a cache, but
if you nullify that benefit it's only approximately a 10% slowdown
even with a huge dbcache.
With a fast SSD (e.g. NVMe) I think the difference between a 400MB
cache and a 5GB one is "only" a halving of IBD time (when syncing from
LAN peers).
To prevent corruption the database updates must involve synchronizing
writes.
We changed how dbcache flushing worked with the explicit intention of
making background flushing possible so that it could be concurrently
flushing and processing blocks constantly rather than inserting these
bubbles where it waits on the disk. Even though the consistency
requirements make that possible now (the UTXO database doesn't have to
be consistent except there is a record that states that all blocks
before it have absolutely positively been applied to the database),
actually making the change is still extremely complicated.
Every time you process a block, once the cache fills you could flush
out to disk the remaining dirty entries for the oldest remaining
blocks until it's back under the limit again.. So essentially flushing
every block in the background.  Then every once in a while, you do a
disk sync and update the record that says where the completely
consistent point is, without having to flush anything additional out.
So almost no latency spikes at runtime.
This would be good for mining but doing that requires a bunch of
machinery to efficiently track things and probably would make sense to
replace the dbcache's map with an open hash table of some kind at the
same time to cut the malloc traffic down by 10x. I expect there is a
factor of 2 IBD speedup waiting from these changes. I'm not sure if
it'll ever happen though, it's a big complicated task and any mistake
is a consensus bug.
You can even do neat stuff like resolve collisions in the open hash
table by displacing the oldest UTXO and once you've gone "far enough"
flush. The table could run extremely close to completely full at all
times.
I'm personally fond of cuckoo tables. Where every item has a small
number of possible locations like two random buckets which each hold 4
items and if those locations are full you pick one, insert the item
there, bump what was in that slot into one of its alternative
locations.
If the table has a little slack  (no more than ~95% full for 2 buckets
of 4 items for example) then it's always successful at finding an
empty slot after a few kicks. Lookup is extremely fast since you only
need to do two random memory accesses. There are a bunch of different
designs though most are best when you can keep the table <50% full but
the cuckoo design is easy to take up to arbritarily high fullness.
The STL sets that Bitcoin uses are a hash table, but collisions are
resolved by having each entry in the hash table be a linked list, so
every access involves several pointer chases and every insertion takes
a malloc.


How different crypto exchange correlate with prices I did searched on how the crypto exchange works, However I do not find the exact answer to my questions.

Let's assume we are talking about two exchanges -
Exchange A - USA based, local (i.e. users kyc based on US identity card like SSN).
Exchange B - Indian based, (i.e. users kyc based on indian identity card like Adhaar)

So Exchange A will have only US users and B will have only Indian users.
Now if US people are believing that bitcoin price will rise and purchase a lot of bitcoin and price increases by some %, how it will affect the price in exchange B?
As 90% of Exchange B users will be sleeping and will not know that price on exchange A is increasing, how it will relate?

Will any user on Exchange B ever be able to purchase bitcoin from any user of exchange A??

The above scenario also make me question how will the very first user of exchange B will buy and from whom will it buy the bitcoin

Edit ---
As one of the answer suggested that Binance.com accepts, I know about binance.
My question is not understood properly here.

Let's take example of newly formed exchange, and exchanges here in India, which accepts only Indian ID card.

How price increase at bianance will affect price at some less known new local exchange?

Your base assumption that exchanges only accept local identities is false. Most accept traders from around the world.

Take Binance.com for instance, which is based in China with servers in South Korea\Japan, and they accept international IDs when you verify your account.


Set up eclair wallet 0.3.1 but cannot send onchain funds I filled my wallet with some btc then wanted to send coins onchain and it seems there is no that possibility ?

Seems like onchain send functionality is not implemented yet. Workaround until then is to import the 24-word seed into another wallet. This can be run in parallel with eclair without problems.


Error when sending rawtransaction I tried to write a transaction on my own in python to better understand how things work; when i decode the raw transaction, it seems properly written.
When I use the rpc method sendrawtransaction I get this error message:

error code: -26
error message:
64: non-mandatory-script-verify-flag (Non-canonical signature: S value is unnecessarily high)

This is the raw transaction:

0100000002b0b7c617588ccf1de8799221bf87a5d70ce47da4e5531d51748c10e1e7755c37000000006b483045022075ff5ff5587b6e6a2f34114bf3801cd2c9b076fe787f5705ca6acd2940d46189022100a65f3f8bd0e3f8c56567b28a37d3c60ff383fb10f416d25261c8453d278f8b81012102b4db032138335cd047878eac44db0dc1714c8ea2eda5079a705bbad6fdaa853dffffffffe59e23b45d3d65abd7b11ef45ca6e37c3193f4ee7c198edee20fbdc76e77f2b5010000006b4830450221008a9dbbe078feed10f50135a5521c18188e782be560ec4c31120dbf4551c6f23602201b1c9e34e1d32de425480b4afcdf5fef4957011511e6c859658c6ad70aca23f3012103fea6936eb5e3fbd4c45a8fae01395972619ef16ba307d1609addfe40668f3ff6ffffffff0580969800000000001976a914db9c91ed4690c016140e84d4d2ec72cb4225e59a88ac80969800000000001976a914d51779439ce3441647f5f4813177be8eb0febd3d88ac80969800000000001976a914fc5da273aea2b3b1346fa9648e4020e7697ceb3b88ac80969800000000001976a91428ef437e0e48b8ed4d65a10ca47a129149de6b4788ac00093d00000000001976a914476f97a1bdd330fae9bbde17de407fbfd409170488ac00000000

How can I fix it ?

Why "decoderawtransaction" works but I can't send it?

Is it invalid or just poorly written?

I am following this approach:
https://github.com/zeltsi/Mybitcoin/blob/master/tx%20with%20multiple%20inputs.py#L79

An these are my tx_tosign:

0100000002b0b7c617588ccf1de8799221bf87a5d70ce47da4e5531d51748c10e1e7755c37000000001976a9147c48aab4405b50ca5394fcf21bc08bb58bc91e0588acffffffffe59e23b45d3d65abd7b11ef45ca6e37c3193f4ee7c198edee20fbdc76e77f2b50100000000ffffffff0580969800000000001976a914db9c91ed4690c016140e84d4d2ec72cb4225e59a88ac80969800000000001976a914d51779439ce3441647f5f4813177be8eb0febd3d88ac80969800000000001976a914fc5da273aea2b3b1346fa9648e4020e7697ceb3b88ac80969800000000001976a91428ef437e0e48b8ed4d65a10ca47a129149de6b4788ac00093d00000000001976a914476f97a1bdd330fae9bbde17de407fbfd409170488ac0000000001000000

0100000002b0b7c617588ccf1de8799221bf87a5d70ce47da4e5531d51748c10e1e7755c370000000000b0b7c617588ccf1de8799221bf87a5d70ce47da4e5531d51748c10e1e7755c37000000001976a9147c48aab4405b50ca5394fcf21bc08bb58bc91e0588acffffffffffffffff0580969800000000001976a914db9c91ed4690c016140e84d4d2ec72cb4225e59a88ac80969800000000001976a914d51779439ce3441647f5f4813177be8eb0febd3d88ac80969800000000001976a914fc5da273aea2b3b1346fa9648e4020e7697ceb3b88ac80969800000000001976a91428ef437e0e48b8ed4d65a10ca47a129149de6b4788ac00093d00000000001976a914476f97a1bdd330fae9bbde17de407fbfd409170488ac0000000001000000

Thanks

The transaction has 2 inputs, and 5 outputs. I see you are on testnet3.
I looked at the S-Values:

 21: OP_LENGTH_0x21:      this is SIG S (33 Bytes)
     00A65F3F8BD0E3F8:C56567B28A37D3C6:0FF383FB10F416D2:5261C8453D278F8B:81
checking S-value is less than N/2, S-value is zero padded - ok

 20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
     1B1C9E34E1D32DE4:25480B4AFCDF5FEF:4957011511E6C859:658C6AD70ACA23F3
 checking S-value is less than N/2, yup... - ok

I don't see an issue here... What have you used unsigned tx?

UPDATE 2018-Mar-10:

Quickly decoding first part of the unsigned transaction:

 01000000
 02
  375C75E7E1108C74511D53E5A47DE40CD7A587BF219279E81DCF8C5817C6B7B0
  00000000
  19
  76A9147C48AAB4405B50CA5394FCF21BC08BB58BC91E0588AC
  FFFFFFFF
  B5F2776EC7BD0FE2DE8E197CEEF493317CE3A65CF41EB1D7AB653D5DB4239EE5
  01000000
  00
  FFFFFFFF

 05
  8096980000000000
  19
  76A914DB9C91ED4690C016140E84D4D2EC72CB4225E59A88AC
  8096980000000000
  19
  76A914D51779439CE3441647F5F4813177BE8EB0FEBD3D88AC
  8096980000000000
  19
  76A914FC5DA273AEA2B3B1346FA9648E4020E7697CEB3B88AC
  8096980000000000
  19
  76A91428EF437E0E48B8ED4D65A10CA47A129149DE6B4788AC
  00093D0000000000
  19
  76A914476F97A1BDD330FAE9BBDE17DE407FBFD409170488AC
00000000

I can see the scriptsig is only filled for one part of the tx. So ok for the first round. Then tx part two is somehow messed up:

 01000000
 02
  375C75E7E1108C74511D53E5A47DE40CD7A587BF219279E81DCF8C5817C6B7B0
  00000000
  00
  B0B7C617  <-- I think this should be FFFFFFFF (Sequence number)
  00000000375C75E7E1108C74511D53E5A47DE40CD7A587BF219279E81DCF8C58...

I thing the sequence number is missing, and then should somehow continue like this:

  Sequence number FFFFFFFF
  OutPoint hash   B5F2776EC7BD0FE2DE8E197CEEF493317CE3A65CF41EB1D7AB653D5DB4239EE5
  OutPoint index  hex=01000000, reversed=00000001, decimal=1
  Script Length   hex=19
  Script Sig      76A9147C48AAB4405B50CA5394FCF21BC08BB58BC91E0588AC
  Sequence        FFFFFFFF

and then the TX_OUT structure...


How was 59 days determined with 1 TH/sec from "Mastering Bitcoin" In Mastering Bitcoin in the section on Difficulty Bits Andreas notes:

  This means that a valid block for height 277,316 is one that has a block header hash that is less than the target. In binary that number would have more than the first 60 bits set to zero. With this level of difficulty, a single miner processing 1 trillion hashes per second (1 tera-hash per second or 1 TH/sec) would only find a solution once every 8,496 blocks or once every 59 days, on average.

How was 59 days calculated?

2^60 (1.15 x 10^18) would be the number of possible values to cycle through and 1 TH/s = 1 x 10^12 attempts every second but what am I missing?

There are 2^256 possible hashes and your source gives a target value of 238348*2^176, requiring more than 60 bits of leading zeros (61 in fact, plus the slightly stricter requirement that a valid hash must be smaller than the target value and not just start with the same number of leading zeros). In fact, the fraction of acceptable hashes out of all possible hashes is 238348*2^-80. Multiplied with 10^12 hashes tested per second, multiplied with 24*60*60 seconds per day, you get a probability of finding a valid hash of about 1 / 58.70 per day, or (as reciprocal) 58.70 days per valid hash on average.

You ask how 8496 was calculated. I note that 8496 = 59 * 24 * 6, so assuming you round to exactly 59 days per valid hash and use the nominal target of having one new block recorded in the blockchain every 10 minutes (hence 24*6 per day), then with a constant, steady-state target you would indeed expect to get lucky, on average, once every 8496 blocks by finding a valid block yourself. Obviously, there is an issue with the stated precision; according to my calculation, even just the rounding to 8500 blocks would only barely be correct.


Why I cannot get transaction from genesis block When I run command

  getrawtransaction
  4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

in my bitcoin-qt console (or bitcoind), I get

  No information available about transaction (code -5)

But I can get raw data about any other transaction.

Here is link to blockchain.info: https://blockchain.info/ru/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

I found answer to my question there: Why can’t the genesis block coinbase be spent?

  For some reason, Satoshi decided not to add the coinbase transaction
  from the genesis block to the global transaction database. Thus all
  the nodes in the network would reject the block.


Is the time taken for the verification of a transcation not much relevant? By verification I do not mean the puzzle solving/hash calculating part but the part involving searching all of the blocks to check if the transaction is valid or not?

For example if A transferred some coins to B ten years ago and after that A didn't make any transaction. Now A wants to make some transaction. To verify this transaction, the miners need to know A's balance which was last updated ten years ago. To do this the miners have to traverse through huge number of blocks to the block of then, won't it take much time?

To do this the miners have to traverse through huge number of blocks to the block of then, won't it take much time?

When A wants to make a payment, he would reference the transaction txid and n in the input from where he earnt the bitcoins that he now wishes to spend. Full nodes generate an indexed database of all unspent transaction outputs (UTXOs), and refers to it when checking transactions for validity. This data is stored in $DATADIR/chainstate and aggressively cached in memory. Thus the nodes do not have to go through all the blocks prior to that, because they have all the unspent outputs handy. This functionality also allows full nodes to prune the blockchain to a desired size without losing the capability of verifying the transactions independently.


convert private key to bitcoin address using python or php I have private key like this 5JYJWrRd7sbqEzL9KR9dYTGrxyLqZEhPtnCtcvhC5t8ZvWgS9iC how to convert to bicoin address using python or php?

example bitcoin address
18V7u8YNHKwG944TCkzYYj32hb6fdFPvQf

I think this video will explain it in details (python):
https://youtu.be/tX-XokHf_nI

Using the code from video, pip packages ecdsa , hashlib and base58:

import ecdsa
import hashlib
import base58

# WIF to private key by https://en.bitcoin.it/wiki/Wallet_import_format
Private_key = base58.b58decode_check("5JYJWrRd7sbqEzL9KR9dYTGrxyLqZEhPtnCtcvhC5t8ZvWgS9iC")
Private_key = Private_key[1:]

# Private key to public key (ecdsa transformation)
signing_key = ecdsa.SigningKey.from_string(Private_key, curve = ecdsa.SECP256k1)
verifying_key = signing_key.get_verifying_key()
public_key = bytes.fromhex("04") + verifying_key.to_string()

# hash sha 256 of pubkey
sha256_1 = hashlib.sha256(public_key)

# hash ripemd of sha of pubkey
ripemd160 = hashlib.new("ripemd160")
ripemd160.update(sha256_1.digest())

# checksum
hashed_public_key = bytes.fromhex("00") + ripemd160.digest()
checksum_full = hashlib.sha256(hashlib.sha256(hashed_public_key).digest()).digest()
checksum = checksum_full[:4]
bin_addr = hashed_public_key + checksum

# encode address to base58 and print
result_address = base58.b58encode(bin_addr)
print ("Bitcoin address {}".format(result_address))


Raw SegWit TX look solid and verifies, but is rejected. Need help figuring out why Consider the following transaction expressed as hex:

  010000000001019F92908527985B1ED14E7F6127684808523750076AB82A03A6A5A50107AC40190000000000FFFFFFFF02446C1E0000000000160014ABFA07FB45DE4B7187360F0B5E4014991666ACCB40420F0000000000160014DFFE4A0C857A04597E0DCB446DB284DD0C068E8602473044022051F99A39749B925E32BF1ED0573ED4CCFC6965F92CD0F016F644C8CF17CA57E102202FCC06C7C26A7E5F71A2DF3353BDE494561E4A6394955DE9C825D08DB573BB1D0121024B2512FFD4AA888E0E0D358083770A4A45093952EE68F3753651932849F008EC00000000

If I paste it into online transaction decoders/validators like the ones here and here, everything looks solid.

But submitting them to any public pushTX API generates an error. The problem is that the error messages are so vague (e.g. "invalid transaction") I'm not even sure where to look.

BlockCypher gives the following error:

  "Error running script for input 0 referencing
  1940ac0701a5a5a6032ab86a0750375208486827617f4ed11e5b98278590929f at 0:
  Script was NOT verified successfully."

I've researched this particular error and people occasionally encounter it when a signature is bad. But I've checked the signature countless times. It's valid. In fact, pasting the transaction here actually shows a little checkmark next to the "signed" icon indicating a proper signature.

Further, the decoders all show the correct inputs, outputs, amounts, etc. So the serialized data doesn't appear to be corrupt or otherwise unreadable.

What could I possibly be doing wrong? I've spent the entire day researching it but can't come up with anything.

It's valid. In fact, pasting the transaction here actually shows a little checkmark next to the "signed" icon indicating a proper signature.

It is not valid. That website did not validate anything. It just checked whether there was something in the scriptWitness field, and if there was, it was marked as signed. That checkmark does not mean that it is valid.

Your signature is simply incorrect. There's no other way to put it. Running it through my Bitcoin Core node gives

64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

which is the typical invalid signature error.

Double check that you are creating the sighash correctly. Problems like this usually are the result of incorrectly serializing the transaction for signing.


Stopping bitcoind on mac One of my kids while learning more about bitcoin started bitcoind on my mac. Now I am unable to stop it. In my activity monitor, it shows a process named "bitcoind". I have stopped that process from the activity monitor various times but that doesn't help. It starts again after some time or in the next boot session. It has been taking a lot of my laptop space (>100gb). I am running low on space and I need to stop it now. This has been happening regularly. As a temporary solution, I used to go to /Users/[name]/Library/Application Support/ and delete the "Bitcoin" folder from there. But that's no proper solution to end it completely. I have tried a bunch of stuff using bitcoin-cli in the terminal. However, I am unable to stop it.
Running
bitcoin-cli stop returns error: couldn't connect to server: unknown (code -1) (make sure server is running and you are connecting to the correct RPC port).
Can someone please tell me what should I do to stop the bitcoind?

Check if you have a relevant setting in one of these

Start up app at System Preferences / Users & Groups / Login Items
Config file at ~/Library/Application Support/Bitcoin/
A bitcoind -daemon in ~/.bash_profile

You could run ps aux | grep bitcoind to check where it is executing from and then delete that folder.


BIP 38 Implementions for Altcoins? Trying to identify implementations for creating BIP 38 encrypted private keys for alternative coins to spark collaborative open source discussions to standardize BIP 38 to support altcoins. Please share any BIP 38 implementation URLs you are aware of that support one or more altcoins for investigative purposes.

The most capable working implementation for extending BIP 38 to altcoins (having strong Bitcoin heritage) is provided by bitcoin-explorer's (bx) Key Encryption Commands (with working examples applied to Dash) that supports both BIP 38 modes:
1. AES256Encrypt, AES256Decrypt - a paper wallet use case
2. EC Multiply - a Casascius use case
A backwardly compatible Proposal and a Table are provided to have deterministic leading base58check encoded characters, apart from the "6P" allocated to Bitcoin, to distinguish BIP 38 encrypted keys from those belonging to different altcoin blockchains. See the BIP 44 Altcoin Version Mapping Table to apply proposed BIP 38 extension to support cryptocurrencies other than Bitcoin (BTC). Also worth examining the BIP 38 Security Considerations wiki page.


Is my cold wallet still cold? I created a new wallet.dat on a dedicated, secured machine with Bitcoin Core.
Then I encrypted it.
Then I sent my "fortune" of coins to it.
Then I backed the file up by putting it on all my disks on my normal PC as well as offline disks.
I even added it to Bitcoin Core on my normal PC, so it now lets me switch between my unencrypted "hot"/"live" wallet and the encrypted "cold" wallet in Bitcoin Core in a very neat manner, allowing me to always look to check that the coins are still there in the "cold" one.
Since I'm afraid to death of losing the encryption password, I did not write it down on physical paper and stick it into the fireproof safe (it could still burn, or get dissolved from water leaking in, or get seized/stolen under gunpoint). Instead, the password is PARTIALLY in various text files backed up on all storage devices I have, including instructions for how to input the rest of the password, which is based on "things that I know very well but others would struggle to guess or find out", such as past pets' nicknames and things like that.
I thought and worried for years before finally coming up with this scheme. To me, it seems like the only sensible solution, having very carefully looked into those hardware wallets and all other (known to me) ways to secure your coins.
My question is: is my "cold" wallet really "cold" if it's literally lying around on my Internet-connected Windows 10 machine, albeit in encrypted form and never decrypted on that machine? Or does it have to always be offline, even if encrypted, to be considered "cold"?

That wouldn't be a cold wallet. A cold wallet is one where the private keys aren't stored on an Internet-connected device, even in encrypted form.
If you just want to check your balance, you should be able to export your addresses, and import them as a watch-only wallet, then keep the private key file (even encrypted) off of your computer. Also, 10+ BTC is far past the point at which I would just consider purchasing a hardware wallet.


How to listen to an address or transaction_id continuously? I am running bitcoin core on my node. I have two questions.

1) I want to get notified whenever there a new transaction in the blockchain.

2) If I give an address, I should get all the details about the address ( when there is a new payment to the address).

I want to make a callback API for the deposits. Could anyone tell how to do it?

Thanks

You can use Bitcoind's ZMQ integration. It lets you get notify instantly when a transaction is made (whatever the address), you can then do the filtering yourself if you want to pinpoint a specific address.

This setup requires a bit of work to do the transaction parsing and filtering, but lets you run without relying on third parties. You won't get the balances of each deposit address too, just the deposits (but you can get the balancet from elsewhere).

Another solution (that relies on a third party) would be to use blockchain.info's service.


What are the limitations of a Client connecting to the Network through TOR? I've recently been reading the Weaknesses Wiki page on "Attack on all users" and I came upon this statement:

  The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this.

Which implies that a Client connecting to the Network through TOR can't fulfil all of its tasks this way. What are the limitations of a Client connecting to the Network through TOR, as opposed to a standard connection?

The Bitcoin client is designed as a peer-to-peer network. To join the network, you need to make a connection to a node that accepts incoming connections. To protect against certain types of Sybil attacks, a client tries to make 8 outbound connections to geographically diverse nodes.

If you connect to the network through tor, you cannot accept inbound connections. You will consume 8 inbound connection slots that were available on the network (with the outbound connections you make), but you will not add any yourself. This can cause the network to run out of inbound connection slots, reducing the reliability of the network. The Bitcoin network, in the past, has had problems with shortages of available inbound connection slots. It's not clear exactly why, but one possibility is intentional malicious consumption of those slots.

The reason you can't fully trust clients that connect inbound to you is that an attacker can trivially consume all your inbound connection slots and all those connections can be from conspiring nodes operated by the same user. However, you have complete control over who you make outbound connections to.

In general, so long as at least one of your connections goes to a well-connected node that is not conspiring with all the other nodes you are connected to, you should be safe.


What's the most popular Namecoin exchange? There are several Namecoin exchanges listed at official wiki and Bitparking seems to be the oldest, but which one is the most used?

Almost everyone seems to use the Bitparking Namecoin Exchange.


The correct term for Bitcoin currency I have been reading about Bitcoin and the history of it. But I was not able to find a term that actually describes Bitcoin.
I am looking for a term that is not only for Bitcoin but any digital currency like Bitcoin.
The closest term I could find was Fiat money, but it is not correct, anyone here knows what the correct term is? Or does the term simply not exist yet?

The general term in widespread use today is cryptocurrency. This refers to a currency designed upon cryptographic principles (as Bitcoin is).

The term "fiat money" refers to the usual money issued by governments. The government declares "this is money" (even though the paper on which it is printed does not have value itself), and people use it as such. Wiktionary defines fiat as:

  An authoritative command or order to do something; an effectual decree.


Why is explorers shows different difficulty values? Just take a random block for example, for block 506068, blockchain.info shows difficulty as 2,603,077,300,218.59, while blockcypher shows 392,962,374, do the explorers use a different way to calculate them, why are they different?

Blockcypher is not showing difficulty but difficulty target. You can see blockchain.info also show this under 'bits'.


What is the optimal way to increment extranonce? I'm trying to learn how to block headers are created and an efficient way of doing so. Given a list .of transactions, can I change the extranonce without having to rehash the entire list?
EDIT: To clarify, I am not asking about what the extranonce is but whether there are algorithms to recompute the merkletree better than others.

The Merkle root of the transactions is calculated by building a binary tree from the transactions as leaves where each parent node is the hash of its two children. As the coinbase transaction is the first transaction in the block, you can store the hashing partners on the coinbase transaction's Merkle branch and only repeat all the hashes to which the coinbase transaction contributes. This reduces the required number of hashes to calculate the new Merkle root for n transactions from O(n) to O(log(n)) given that no other transactions in the block were changed.
There is no way around repeating the whole left flank of hashes in the binary tree, since changing the extranonce in the coinbase transaction changes the outcome of the bottom left hash combining coinbase transaction and first regular transaction.


Fee height vs. TX value - limit? Is there a particular reason fees higher than the transaction volume are allowed?

What about imposing this:

Smallest output must be at least 10 times the fee.

Might reduce Spamdice transactions (thinking of losing bets notification).

But what if you really needed to pay someone a fraction of a transaction fee? Bitcoin is indiscriminatory in that regard.

Moreover, most transactions have two outputs, one crediting whoever you send your transaction to, and one crediting you back. It is quite easy to send the same small amount transactions to someone while still appearing to be sending a large amount of money in total (the remainder would be sent back to you).

Anyone can enforce arbitrarily low or high transaction fees and modify their software to exclude any and all transactions they don't like (for example, I have heard Luke-Jr's pool does not process SatoshiDice's transaction at all). In the end, it is the will of the people and the miners that will determine the correct fees and rules, not some fixed mandate.


Generating paper wallet offline with liteaddress GitHub download After extracting all the files from the .zip file available at GitHub, which of the files do I need to open from the download in order to generate keys offline. Is it the bitaddress.org html file? Should I open it with my browser?

Yes, you open the HTML file in a web browser.
You can use either bitaddress.org.html or index.html

Just so you know, none of the files are signed, so you can't verify the authenticity. I believe the devs just don't give a fuck anymore :D
To be on the safe side, disconnect from the internet before you run the key-generator.


Who controls Solidcoin's special millionaire accounts? Solidcoin takes the following approach to preventing the 51% attack:

As with existing cryptocurrencies, SolidCoin 2.0 stores transactions in a "block chain" which is essentially what it sounds like. Transactions go into a block, nodes do work on that block to verify it, and if the work is good enough they can submit it to the rest of the network. SolidCoin 2.0 then comes into action, every other block in the chain must be worked on by someone with at least a million (1,000,000) SolidCoins in an account.
One initial problem with this p2p security feature is SolidCoin only had 1.112 million coins prior to this security feature being implemented. To solve this, 10 accounts of 1.2 million were created in the genesis block. These are special accounts that cannot be spent on the network, effectively making them "Null accounts used for special purposes", until SolidCoin does have real millionaires.

So, who controls these ten special purpose accounts? And are they supposed to be disbanded when real millionaires come around?

RealSolid controls those accounts. He claims that he has selected several trusted people to operate them, but we have no way to know if this is true or not.

There also seems to be a somewhat fundamental flaw in the reasoning. If we trust people because they have the most to lose, why should we trust people who have unspendable coins? Unspendable coins don't reflect having anything to lose at all.

It should also be pointed out that those with more than a million coins have complete control over the transactions included in the chain and who gets all of the mining rewards. They have merely to announce blocks in pairs -- everyone who doesn't control a million coins can be completely locked out by those who do.

Also, I think "the poor can trust the rich because they have the most to lose" fails the giggle test. (That is, you can't say it with a straight face, so it's probably not even close to true.)


Bitcoin mining question about hashrate helping you exponentially I am a total newb in the crypto mining world and was researching the profitability of bitcoin mining when I came across bitclub which offers almost 4x more profit than mining by yourself. Their argument is that they have more hashpower so they make more bitcoins exponentially. Is that true? Do we make more bitcoins exponentially if we have more hashpower? If I were mining with a super computer, would I make exponentially more bitcoins or would it be the same as per 1H/s multiple by the hash power you have?

That seems to good to be true and probably is a scam. The word 'exponentially' is being used with no regard to what it really means.

To mine 'exponentially' more coins you have to have 'exponentially' more hashpower.


Why does bitcoin uses INIT_PROTO_VERSION (209) for addrme and addryou in the Version Message Why does Bitcoin use INIT_PROTO_VERSION (209) in the addrme and addryou message of the Version Message? Why is it not using the nodes protocolVersion which had been advertised in the same Message.
This is part why the nTime from the node in the Version Message will be ignored
Code used for Debug in protocol.h
   SERIALIZE_METHODS(CAddress, obj)
    {
        SER_READ(obj, obj.nTime = TIME_INIT);
        int nVersion = s.GetVersion();
        if (s.GetType() & SER_DISK) {
            printf("nVersion %d\n", nVersion);
            READWRITE(nVersion);
        } else {
            printf("Not evaluated nVersion %d Type %d\n", nVersion, s.GetType());
        }
        if ((s.GetType() & SER_DISK) ||
            (nVersion >= CADDR_TIME_VERSION && !(s.GetType() & SER_GETHASH))) {
            READWRITE(obj.nTime);
            printf("nTime %d\n", obj.nTime);
        } else {
            printf("Not evaluated nTime %d\n", obj.nTime);
        }
        READWRITE(Using<CustomUintFormatter<8>>(obj.nServices));
        printf("nServicesInt %d\n", obj.nServices);
        READWRITEAS(CService, obj);
    }

See below the Output
BTC's
Receive addrMe
Not evaluated nVersion 209 Type 1
Not evaluated nTime 100000000
nServicesInt 0
Receive addrFrom
Not evaluated nVersion 209 Type 1
Not evaluated nTime 100000000
nServicesInt 1033
2020-07-07T01:35:08Z New outbound peer connected: version: 70015, blocks=638069, peer=1 (full-relay)

Is this a wanted behavior?

CAddress is serialized differently for different purposes. When serialized to disk, the node version and the time are serialized. This is because this information is relevant to the address manager.
However, when serializing to be sent to another node, both the version and the time are omitted because they aren't necessary. These aren't being sent to other nodes, just the IP address and port themselves. You can see that these are skipped for non-disk operations because it is doing if (s.GetType() & SER_DISK) before the READWRITE (which indicates de/serialization) for both nVersion and nTime.
The output you see is because addrMe and addrFrom are local variables which don't need to have the correct version and time. So the version used is the version for the stream which is the minimum protocol version (this is just a safety thing to ensure compatibility). The time is the default minimum time. Since these values don't matter, using these defaults is okay.


Can an attacker flood the Bitcoin network with fake transactions? We are in 2050. People show an ever-growing distrust in the global banking system and start transitioning to only using Bitcoin: most companies accept it as a form of payment, and people settle their bills with Bitcoin. Even the kid with the lemonade stand down the road accepts Bitcoin as her payment.
Banks are worried because they are losing customers and revenue. Legislation has not managed to protect banks and the smaller ones have already started to shut down or provide alternative services.
Then, the CEOs of Atlantis Bank and River Banks, who are the only healthy banks remaining come up with a plan:
A transaction's hash can easily be checked. Why not attack the Bitcoin network with an insurmountable number of fake transactions! We will produce so much noise, and the network nodes will be occupied with checking our fake transactions instead of the real ones, so much so, that a considerable fraction of the total network computing power will be devoted to checking fake hashes. Real transaction verification will come to a halt, and people won't be able to do any everyday trade. They will only be left with one option: return back to us.
Here is my thinking:

Bitcoin's blockchain is increasing in size.
More nodes are added to the Bitcoin network.
Nodes are getting faster.

I expect this to have an overall quadratic effect (in the best-case scenario) in this attack: it will be cheaper for the attacker to generate and submit fake transactions, but it will also be cheaper for the network to reject the fake transactions. BUT the blockchain is increasing in size so at some point the network will be at disadvantage.
Here are some back-of-the-envelope calculations I made, assuming a constant blockchain size of 15 GB:

SHA256 efficiency with today's processors: 45 cycles/byte;
So a chain of size 350 GB, requires 1.6e+13 cycles to be rejected as fake.
With 1 core syncing at 3.5 GHz, this will take 4500 s (1.25 hr).

Are my premises wrong? Won't there be a turning point, when the cost of the largest banks losing customers will be greater than the cost of them launching such an attack (in full secrecy)? How can the network defend itself against these attacks? Sure, one can always add more nodes to the network increasing the fee, but won't that also turn customers back to the banks (i.e. rendering the attack successful)?

It seems like one of the basic assumptions you are making is that all transactions ("fake" or not) are added to the blockchain. But that is not the case. Only valid transactions can be included in a block and thus added to the blockchain. So even if some bad actor spams invalid transactions, these won't get added to the blockchain and force new nodes to sync them.
Furthermore, nodes will only relay blocks and transactions that are valid. If they are invalid, then they will not be forwarded on to the node's peers. Additionally, nodes have local Denial of Service protections. If a particular node is sending multiple invalid transactions and blocks, then the node will disconnect them and even refuse to accept a connection from/to that node (aka the malicious node is banned by the local node).
So a bad actor could make nodes that connect to many other nodes and try to spam them, but they will find themselves quickly peerless as everyone disconnects and bans them. Of course the way around this would be to change their IP address, but this means they constantly have to do that, just in order to get disconnected and banned. It would be essentially impossible to maintain a sustained attack on the network in this manner.
Lastly, the bad actor would only be able to do this to nodes that accept incoming connections. Nodes that only make outgoing connections would be unlikely to connect to the bad actors nodes, at least after they have changed their IP address once. This is because nodes that only make outbound connections only connect to nodes that are considered "good", which includes things like long uptime. So the bad actor would have to maintain a node for a while (so it has a long uptime) in order to get incoming connections from outbound only nodes. But once they start spamming, they get disconnected and banned as they would for nodes that accept incoming connections. From that point on, nodes will not make outbound connections to it because it has misbehaved or because it has changed IP addresses and the new IP address does not have a long uptime.


Can anyone delineate a phrase in the Satosh's white paper?: limiting the minimum practical transaction size Can anyone explain what the phrase below, from the Satoshi Nakamoto white paper, means?

Introduction

The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions

Can anyone tell me what the writer tried to say?

What Satoshi is referring to is the traditional financial system's inability to transfer small amounts of money.  Traditional money transfer systems such as ACH and various wire transfer services are reversible for a certain period of time, meaning that there is some risk involved.  The risk that the bank will have to mediate a reversal in payment (which costs them money) makes it so that they need to charge fees in order to transfer money on your behalf.  If the fee is not worth the risk, the bank won't do the transfer.

Let's take the example of paying a friend $5 for picking up the tab at lunch.  You tell your bank to transfer $5 to his bank over the ACH system.  This system takes 3-5 days to complete the transfer.  During that time period, a reversal is possible, and if it occurs, the bank needs to use its resources to mediate it.  This might include retrying the transaction, contacting the other bank, or contacting the customer in the case that the $5 has already been withdrawn.  These actions all cost the bank money.  If the probability that a reversal will occur, P, multiplied by the expected cost to the bank for dealing with the reversal, C, is greater than the fee the bank will earn, F, then the bank shouldn't allow the transaction.  So we have a system where the following must be true:

F > C x P

Let's say the bank charges a percentage as a fee, let's say an outrageous 10% of the transaction.  That means 'F' is $0.50.  In this scenario, it is unlikely that C x P will be less than $0.50, so the bank can't do the transfer.

Let's say that the bank charges a flat rate for transfers, one that will cover any of the risk.  A value of $10 for a transfer of any amount would not be unreasonable from the bank's standpoint.  However, would you be willing to pay the bank $10 to transfer $5 to your friend?

This is just one of the many problems that Satoshi solved with the invention of the Bitcoin blockchain.


Can Bitcoin(PoW) work under partial synchrony? This paper rigorously proves that Bitcoin can achieve consensus under the assumption of bounded message delivery time:

  Messages  in  a  mailbox may  be  delivered  in  any  order,  and  at
  any  time,  except there is a maximum delay of ∆

If I understand it correctly, this only proves it works in synchronous network. If so, this assumption seems relaxed to me.

Tendermint paper claims it can work under the partial synchronous assumption (from DLS paper):

  There is assumed to be some unknown upper bound ∆ on the time of
  messages to be delivered.

The setup is more general in that the upper bound ∆ here is unknown.

Can Bitcoin protocol achieve consensus in partial synchronous network as well? Is there any theory work dedicated to proving that?

If I understand it correctly, this only proves it works in synchronous network. If so, this assumption seems relaxed to me.

The Bitcoin network is not synchronous, it is asynchronous and maintains consensus.

  Can Bitcoin protocol achieve consensus in partial synchronous network as well?

Since Bitcoin is an asynchronous network and achieves consensus, it stands to reason that Bitcoin would be able to achieve consensus in a synchronous or partially synchronous network as well.


Why importing private key from one HD wallet to another doesn't restore the balance? I've seen similar questions here but didn't find an answer
I look for a private key in Exodus, for example, and import it to Jaxx and I don't see my balance correctly
So my questions is, do all HD wallets generate public keys from private in the same way?
Also, for example, there are wallets that do not allow to generate new public address, does it mean that wallet is bad?
And if public keys aren't generated in the same way then does it even make sense to keep you private key on paper wallet if you won't be able to get your funds then?

do all HD wallets generate public keys from private in the same way?

No, the "derivation path" is an important additional piece of information. You should be prompted for this when importing / sweeping a private-key

See Default derivation paths


How do 'Sphinx' invoice-less payments on the Lightning Network work? There was recently a WIP draft published to the lnd Github, for a 'Sphinx payment mode' for Lightning Network nodes. To quote Roasbeef from the Github PR:

  [this allows] the ability to send a payment to a destination without first needing to have an invoice

Though this is a WIP, it can apparently be used on mainnet already, as long as all nodes involved are upgraded to include the new code.

So how does this work? At a high level, what does the UX look like? At a low level, what differences are there in terms of completing the payment (passing HTLCs around), compared to a standard LN transaction? Whats going on under the hood?

Usually a merchant will generate a (psuedo)random 32-byte value and hash it. This becomes the payment_hash which identifies the payment in the network and is transferred to the purchaser in an invoice. When the user makes the payment, they send this payment_hash with an onion packet, as a conditional payment which will complete if the preimage of the hash is provided. Each hop will forward this payment hash, until the destination must reveal its preimage to the penultimate hop in order to complete the transfer of funds. The hops will then transfer the preimage backwards through the route until it reaches the purchaser, and serves as proof that the payment suceeded, under the assumption that nobody other than the merchant could know the preimage. This prevents reuse of a payment_hash because an intermediate hop may have knowledge of a preimage which has been used already.

The HTLCs are exactly the same with spontanious payments, the difference is that the purchaser creates the payment preimage and payment_hash. The payment_hash is transferred as usual, but the preimage is encrypted inside the onion routed packet in a way that only the merchant can decrypt it.

The onion packet has 12 bytes of padding at each hop which can be utilized to send additional data, but also, the onion packet can have "virtual hops" after the destination hop of the payment, which the merchant can decrypt. These virtual hops can contain 32 bytes of data because the usual amount, SCID and cltv fields can be repurposed to hold additional data, since you're not forwarding any payment beyond the destination. A couple of bytes are used as flags to indicate the type of data, and the aggregation of the extra data in the virtual hops is known as the Extra Onion Blob (EOB).

The entire onion packet remains the same size, so the amount of additional data which can be transferred with the payment is still limited, with the more hops required for actual payment, the fewer virtual hops. A spontanious payment requires at least 2 virtual hops because there are flags and a 32 byte primage to encode into the EOB.


What will be the price for BCC bitcoin cash on August 1st? Will there be an "initial price of a chain fork" type of opening when this new BCC comes out? Or the price will be same to the regular BTC that we currently use?

The initial price of BCC will be what the first buyer is willing to pay for it on an exchange. After that, it's simply a matter of demand and supply.

According to coinmarketcap.com, BCC futures are currently trading for $332. This is probably the best indication of what to expect once the market opens.


Claiming my BTG from my BTC private key I have a BTC private key, how do I get my BTG? I have tried a few methods and tutorials but none seem to be working.
And beside that, is there any working BTG explorer? All the ones I found seem to be buggy (including btgexp.com) and wont recognize my address.

EDIT: yes I had BTC on this address at the time of the split

EDIT 2: found a working explorer with https://bitinfocharts.com/bitcoin%20gold

EDIT 3: yes I have transferred all my BTC to another address, and I just want to get rid of my BTG now

AFAIK there's one good wallet other than the reference client that can import the private key and make a transaction.

That's Coinomi, it can import the private key and does support BTG.

(When I wanted to dump and sell my BTG, Coinomi was great, although I needed to use the Android emulator Genymotion [because I don't have an android device])


Is each Bitcoin address unique? I am wondering whether each bitcoin address is unique. I would assume yes. Then, how is this enforced given the distributed address generation?
As I understand it, each time an address is generated, a new key-pair is also generated. On what basis is this done? Since the address is the hash of the public half of the key-pair that would also allow (at least theoretically) multiple public keys to have the same hash.

TL;DR: There are so many addresses that it is improbable that anyone will ever generate a duplicate of another address in use – as long as random number generators work as they should.

2^160 possible addresses

Bitcoin addresses consist of an alphanumerical string with a length of up to 34 characters, excluding the capital "O", the capital "I" and the lowercase "l", as well as the number "0". This would allow for 58^34 possible combinations, however, as some of the positions are used for a checksum this is reduced to 2^160 valid addresses. The checksum on the other hand allows to detect mistyped addresses as invalid, so that it is highly unlikely to accidentally input another valid address.

Chance of 3.42*10^(-27) for a collision at one trillion addresses

Even if we generously assume that at some point there will be one trillion addresses (approx. 160 for each of this planet's population), according to the simple approximation formula for the Birthday attack given on Wikipedia, the chance is 3.42*10^(-27) that any two of those Bitcoin addresses collide. In comparison, the figure of addresses that were ever used to receive bitcoins was just over 13 million in May 2013.

Address space could be augmented

Especially as the protocol at any point could be adapted to accept even longer addresses, we can say, yes, it is theoretically possible, but unlikely enough that we can assume for our purposes that it will never happen.*

It's impractical to generate addresses for gain

To answer your other question: For each address there apparently are 2^96 different private keys whose corresponding public key will map to the same address. So to actually try to pursue Bitcoin theft, it would be much more sensible to just generate random private keys and hope to find one that has a corresponding address with money on it. In all likelihood the power for such calculations would cost more than anyone could earn with such a scheme.

*As long as certain random number generators work as well as they should... :)


How do nodes validate that a UTXO in a new transaction is unspent? Does it check every block in between where the UTXO first appeared and the current time to make sure it didn't get spent then? Or is there some other caching or other method to make the check faster?

Does it check every block in between where the UTXO first appeared and the current time to make sure it didn't get spent then?

Yes, but this check is not done for each UTXO individually as transactions come in, it is an ongoing process that specifies the current state of the network.

A bitcoin node will independently work through the entire transaction history of the network, and while doing so it will build an index of unspent transaction outputs (UTXOs), which are, as the name suggests, transaction outputs which have not yet been spent, and thus are valid to be spent on the network. As new outputs are created, they are added to the UTXO set. Likewise, when a UTXO is consumed as input to a transaction, it is removed from the UTXO set. So any valid new transaction must specify one or more of these UTXOs as inputs (with the exception of coinbase transactions, which do not have any inputs).


What are the risks of a lower-than-95% activation threshold for soft forks (particularly SegWit)? 95% seems exceptionally conservative, especially given the evidence of vetoing by a subset of Bitcoin miners. What risks does, say, 60% over a longer activation period hold vs 95% for SegWit?

There are two related risks:

Activating without a majority of hashpower supporting it over the long term.

Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66.

What you now have is a situation where nodes that enforce the new BIP66 rules will not come to consensus with nodes using older rules.

There's no perfect solution to this problem. As a miner, how can you prove that you won't change implementations after the activation point? The solution so far is to require 95% agreement to upgrade, on the theory that as long as less than 45% falsely signals, you'll be OK.
Miners running old code may still produce blocks, fooling SPV/non-upgraded clients.

At some point, someone will probably make a block that complies with the old rules, but not the new rules. Bitcoin Core won't do this by default, but it's probable that at least one miner will modify their code, or run some weird set of software, or even maliciously create a block to make a 51% attack easier.

Old nodes will accept this block, and try to build on it. Even if non-upgraded miners are in the minority, they're still going to manage to build chains of several blocks by pure chance sometimes. These will be orphaned eventually, but in the short term people may rely on them being valid, and be harmed by that.

It's worth noting that lowering the threshold to 60% would likely still not activate segwit. Segwit signalling is currently about 30%.


Contracts Benefit of Merchant I was wondering if some one could explain to me, in this example what the benefit of the website owner(s) is? It seems to me they do not benefit at all from this contract. There are obviously benefits to the user, namely they cannot possibly lose their bitcoins from what I can tell. In this scenario, what is the 'payment' that the user making besides not having access (as far as I can tell no one has access) to their coins for 6 months?

In the example, the user is demonstrating that they are willing to lose access to some amount of Bitcoin for a period of time.  The example is based on an assumption that a rational user wouldn't do that unless they were serious about something.  The implied benefit is that casual users or bots won't want to put a lock on their funds.

However, as Tadje Dryja pointed out in a recent talk, time value of money is not necessarily equal among users.  In the example, the contract is for 10 BTC.  For some folks 10 BTC may be a lot to part with for 6 months.  For others it may be no big deal.  So it's questionable if the site gets the benefit they think they are.

Imagine an exclusive club where you had to deposit $1,000 just to get in the door, but you were guaranteed the return of your money when you left.  It does act as a selection filter for who is able and willing to go through with this arrangement.  Whether or not it really selects for the clientele the club is looking for is another question.

Also, at the risk of pointing out the obvious, I would add a step 7 to that example that the web site verify that Tx1 is confirmed on the block chain and is as expected before proceeding.  The web site already knows the transaction ID for Tx1 since that was given in step 3.


Why are some Bitcoind commands comparatively slow? For example, running bitcoin-cli getbalance <address> on an arbitrary, watch-only address takes around 6-7 seconds for a response. Is there any way to improve the response time?

How do API services like Blockchain.info return balance details almost instantaneously? Each API call to Blockchain.info takes less than half a second for a balance request. Is there a way for me to do that with bitcoind?

For example, running bitcoin-cli getbalance <address> on an arbitrary, watch-only address takes around 6-7 seconds for a response. Is there any way to improve this?

Besides the fact that this is not how getbalance works (you don't call it on an address), getbalance is slow here because it must go through the list of transactions for the addresses in your wallet and sum their outputs to get the balance. If your wallet is very large and has lots of transactions or you are running bitcoind on low powered hardware, this could take a long time.

  How do API services like Blockchain return balance details almost instantaneously? Each API call to Blockchain takes less than half a second for a balance request. Is there a way for me to do that?

Those API services have several large servers hosting their databases. Their databases are massive and index everything in the blockchain. They store information like the balance of each address (which is technically not in the blockchain) so when you ask for the information, it is pulled from the database very quickly. Bitcoin Core does not do this as such databases are a waste of space and most users will not be affected by the slower functionality.


In a Proof of Stake (PoS) mining scheme what prevents miners from producing many more blocks or inflating the currency? In a traditional Proof of Work (PoW) scheme it's assumed it takes some amount of time to compute the PoW function, such as SHA256x2 in Bitcoin and the difficulty increases as the network is capable of mining faster than the target 10 minutes.

In many Proof of Stake (PoS) schemes other metrics are used to determine if a miner was "selected" to have stake in the block, usually by looking at bits of TX inputs.

What keeps a PoS miner from having essentially infinite TX input hashes available on hand at any moment and mining blocks at a fast rate to inflate the currency / collect lots of subsidy rewards?

There are many different proof of stake schemes, so let's just pick one to talk about. I will be talking about the one that was originally based in Peercoin and is now used by many other coins. And I will be talking about the latest version of that scheme as it evolved during the time from being very much insecure to be little more secure, but still way less secure than proof of work.

So the concept of difficulty remains there. If you mine blocks to fast, difficulty increases and you need more luck to be able to produce next block.

Another important characteristics is that the number of UTXOs does not matter that much. It helps you if you have many of them, but in order to be able to create next block, your chance is proportional to the total sum of the values of those UTXOs. Therefore imagine you have one UTXO with 1000 coins and someone as has 1000 UTXOs with just one coin. Your chance to create next block is the same, assuming we take just one round in isolation.

Only in long term due to other properties of the algorithm, it is slightly better to have many UTXOs. This is because once the UTXO is used to create a block, the new outputs of that transaction are forbidden to participate in block creation for some time.


Use of Bitcoin paper wallet A Bitcoin paper wallet contains a pair keys: public key (address used to receive coins) and private key (allows to spend coins stored at that address).

Those keys are printed in a form of QR-codes so that everybody can quickly scan them and add the keys to a software wallet to make a transaction.

Now, if I lose my Bitcoin paper wallet, someone who finds it, is he able to spend my coins by scanning QR-codes ? And if yes, is this type of wallet secure ?

Yes, if someone locates the paper wallet and is able to read the key on it, they can spend any BTC sent to that wallet.

The wallet is secure if used correctly. Paper wallets are usually intended to be stored in a safe place, such as a literal safe or bank vault. They are not meant to be left on desks, dropped on the street, etc.

Additionally, you could utilize BIP38 to encrypt the private key on the wallet with a passphrase, that only you know.

Remember, any system is only as secure as its weakest link. Even a state of the art hardware wallet is useless if your seed word backup is easily accessible by an attacker, since they can recover the entire wallet from that.


Where can I get a list of places I can use my Bitcoins? I am new to Bitcoin and I'm trying to understand how it works and how I can make it work for me.

So, let's say I travel often to different Spanish speaking countries in South America and Spain. How can I acquire a list of all the vendors, merchants, services, etc. that use the Bitcoin exchange in all these areas to avoid using the banking system of "money transfer?"

You can try CoinMap. It's the largest database of physical locations that accept Bitcoin.


Question: Docker alternative to Tails OS for generating Bitcoin addresses securely for cold storage I am exploring options to generate Bitcoin private keys and addresses in most secure ways, using Ian Coleman's BIP39 tool. https://iancoleman.io/bip39/
The most recommended OS seems to be Tails OS for using this tool in completely offline mode.
If I used any other minimal linux image in docker, such that it never connects to internet , wouldn't that be equally safe ? We can also ensure to destroy the container and image from local storage after the address generation.
Do I really need Tails OS for this specific use case ?

It would not be equally safe because you are running the container on a machine that is connected to the internet. Even if the guest is not compromised, the host could be, and that would compromise the guest.
Furthermore, docker containers are not even fully fledged virtual machines. They share the host's kernel as well as a lot of other components from the host system.
In the end, the software that you run in a docker container gets executed by something in the host OS, and that has the potential to leak information to an attacker who has compromised the host.

Running Tails on an offline machine removes any existing OS as a factor since Tails is itself a fully fledged OS running on bare metal. You can ensure that the Tails you are running is that which is officially distributed, thereby ensuring that there isn't something else which has compromised it (of course there is the risk that Tails itself is compromised, but that's a different discussion). By physically disconnecting the device from the internet, there is no way for anything to leak to the internet.


If 30% of the network are malicious, how many nodes would an SPV need to connect to, to be sure? If we assume that 30% of the network is malicious and colluding together to trick an SPV client, by telling him wrong information.

How many random connections would the SPV client, need to connect to before the probability that he has only connected to malicious nodes is negligible?

In other words:

If we assume that the SPV does not know that 30% of the network is bad. What is the probability that he randomly connects to 5 bad nodes in a row?

Under the assumption that the total node count is large enough that we don't have to care about the reduction of the ratio by only connecting to nodes we haven't connected to, yet:

The chance to connect to five bad nodes in a row is 0.35 = 0.00243 = 0.243%. AFAIK, many SPV nodes only connect to 4 nodes, though. The probability then is 0.81%.


Simulate an FPGA/ASIC on RAM for mining? Just out of curiosity, would it be possible to use a lot of RAM and treat it as an FPGA capable of mining other cryptocurrencies, or would it be too expensive to implement and not worth it?

The statement "treat it as an FPGA" doesn't make sense. Both RAM and FPGA (or ASIC) are electronics but that's where the comparison ends. RAM is designed for one specific task and cannot by itself do calculations required for mining.


BFGMiner No device detected I am completely new to Bitcoin.
I am trying to connect Slushpool using BFGminer, but its showing some USB device not detected?
I am a newbie and don't know which device it needs.
What should I do?

The best gaming PCs gave up in 2013. Now you need ASIC hardware to mine. Even 1 TH/s (1000 GH/s) is not fast anymore - I wouldn't buy slower than that. The device bfgminer is looking for is an old and slow ASIC that connects to the USB port of your PC.

Modern miners are stand-alone machines which connect directly to your network, not to your PC. You don't need your PC or bfgminer for the mining. You use a browser on your PC to configure the miner, after that it mines on its own.


what happens to low-fee or forgotten transactions If a transaction has a fee that is too low then it is possible for the transaction to either age out of the mempool (14 days) or get removed because the mempool reaches its max size. So what happens to that transaction? At some point the transaction is "forgotten" so the sender has the funds available to him again. But how does this happen? Since each miner has its own version of the mempool, is it possible for the transaction to still be in one miner's mempool but not other miners' mempools? How does the network of miners "decide" that the transaction is forgotten so that the sender now has the funds available to him again? And could that person resend that same transaction or does the sender have to create and send a new transaction?

Likely the transaction will be kicked out of the pool - purging it from the node's "memory". Its hard to imagine that there would be a transaction that would qualify for that treatment with one node, but not for others.
But anything is possible.
If that were the case, then that transaction would just remain hanging in the mempool for that particular node that decided to keep it (for whatever reason). For this portion of the protocol though, its more important to take into consideration which action the network would take overall.
How That Specific Node May Handle Things

There's a chance you may attempt to send a duplicate transaction (from the perspective of that node), unwittingly.

Unless you had the RBF flagged ticked for your TX (which there's a good chance that you may have since this is default Electrum behavior along with many other wallets), the node will reject that new transaction attempt since its likely coming a million years after you sent the initial one

Assuming most of the network purged that TX though (they probably did), however that node decides to handle your re-broadcasted TX (if you do that), is neither here nor there


I am going to buy bitcoins for the first time from a seller on LocalBitcoins. Please guide me. I am going to buy bitcoins for the first time from a seller on LocalBitcoins. He says that funds can be transferred via internet banking. He seems to have good feedback, 9+ reviews but I am kind of nervous. What exact steps should be followed for a smooth transaction?
My plan is:

Send him my wallet address, and then wait for him to transfer the bitcoins.
Upon successful transaction, I send him the required amount through an online bank transaction.
??
Profit

I hope I am doing this right. Please advise.

Meet him at a public place and do the exchange using a phone bitcoin-app and cash. Make sure that his reputation is worth more than a possible robbery/scam.


Is BitCoin still uncontrolled with all those mining pools? It is always stated that BitCoin is uncontrolled and it does not make sense to cheat and double-spend because you will need more computing power than everyone else combined. Isn't that changed with mining pools? I can see top biggest mining pools controlling 75% of computing power. If they are in agreement, can't they (by "they" I mean pool managers) cheat on almost every transaction? Aren't pools becoming kind of uncontrolled authority in BitCoin community, What is controlling them?

To an extent yes. It's bad that mining pools are so big and fairly concentrated. Work is being done to try to alleviate this.

A few points limit the threat though:

The amount of harm miners can do is limited. They can't outright steal money, or create more money out of thin air. The damage would be in the order of double spending (resolution: wait for more confirmations) or censoring transactions (which a miner doesn't really have an incentive to do unless paid a lot by someone else or forced by law).
Individual miners can switch (they have in the past) to other pools if the pool operator goes rogue.
Pool operators would be digging their own graves if they do evil things: the Bitcoin price would plummet, costing them a lot of money and lost investment.
As a final resolve, when things turn really ugly, Bitcoin could change the proof of work algorithm, making ALL mining equipment obsolete. Miners are basically hired by the Bitcoin network to do some work, if they perform poorly they can get fired.

So, although far from ideal, there still are incentives to keep miners honest and rules that limit their dishonesty.


Fee negotiations in Lightning How are fees negotiated in multi-hop payments in Lightning?

Imagine a four-hop payment: Alice -- Bob -- Charlie -- Dave. Bob and Charlie advertise fees of 100 sat each, Alice thinks it's reasonable and starts routing the payment through this route. Does Bob know which part of the expected payment is intended to be a fee? What is Bob forwards the payment to Charlie taking 120, 150, or 200 sat instead of 100 -- what does Charlie do?

Is there anything that prevents intermediary nodes from lying about their fees?

The situation you describe cannot happen / would lead to a routing failure. I have created an 11 minute video explaining how htlcs are used in onion routing. Parts of the video (rather at the end) explain how fees are encoded within the sent onion. I think watching that video is the quickest way to understand the fee model of the lightning network.

A tl;dw (too long didn't watch) answer looks like that:

If a node decides to maliciously collect a larger fee and forward the onion. The next hop will not be able to collect the fee as it advertised and will fail the routing process. In your setting this means charlie decrypts his onion and sees which amount to forward and sees from the incoming htlc that it would only receive a fee of 80 / 50 or 0 Satoshi instead of the advertised 100. As said charlie would fail the onion but not be able to blame Bob. Actually obs behavior would confuse Alice as she chose the correct fees. Alice could assume Bob was a bad routing node and elect a different part. However this mechanism is as far as I know not implemented yet.


BlockChain scalability: How does BlockChain process multiple parallel transactions? I just did some introductory research into blockchain technology and this is a breakdown of my understanding of how it works:

Scenario: Assume Trump wants to send Obama 5 bitcoins. As soon as this transaction is initiated:

miners in the peer to peer network will (individually?) start solving for the next valid hash in the block chain. ( does the peer network use the combined processing power to solve together, or do nodes solve individually independent of each other?)
Once the valid hash is discovered, the node that did the discovery will be rewarded with a set of bitcoins
The ledgers at each node will be updated with the Alice -> Bob transaction, while this newly discovered hash will be a representation of the same. This should approximately take  about 10 minutes?

Now there is a good chance my understanding is completely off, but my question is this:

Lets say 1000 transactions are initiated at the same time. Regardless of this, the peer network will be solving for the next hash in the blockchain which will verify 1 transaction. So the 1000 transactions will be verified sequentially as the miners proceed from one valid hash to the next.

If solving for one transaction takes approximately 10 minutes, this would mean to completely verify the 1000 transactions (initiated at the same time) it would take around 1000 x 10 minutes!

Clearly this problem is handled in someway in the real world as i'm pretty sure thousands of bitcoin transactions take place at any given time without a delay like this. Some clarification would be hugely appreciated. thanks!

You should probably read up a bit more, but here's some help:

  miners in the peer to peer network will (individually?) start solving for the next valid hash in the block chain. ( does the peer network use the combined processing power to solve together, or do nodes solve individually independent of each other?)

Nowadays miners work together in mining pools.  These are not part of the actual protocol, but is just the way the mining ecosystem has evolved.  As far as the Bitcoin protocol is concerned, you can look at an entire mining pool as an individual miner.  Each pool is responsible for trying to make their nodes work in parallel.

  Regardless of this, the peer network will be solving for the next hash in the blockchain which will verify 1 transaction

This is where you are wrong.  The hash is for a block of transactions, not an individual transaction.  For many reasons, it is advantageous to do the proof of work on blocks rather than transactions.  See this question for more explanation on that.

I hope this helps.


Who needs a copy of the entire blockchain these days? As discussed in this question there is a news report today saying that researchers have found illicit files and information stored in the blockchain.

In today's Bitcoin world, who needs the full block chain?  With mining pools and online wallets looking like the norm (is this true?), do many people at all download the entire chain, or at least large portions of it?  I'm sure that researchers will download it in full, but what are the other use cases?  Does it extend at all to any casual users?

Running a full node (downloading the blockchain) allows a user to interact with the network, without having to trust any other network participant.

For some users, this may not be important, but for many users it is very important. For example:

You are a business, and you need to ensure that txs you send and receive are in fact being communicated across the entire network.
You run an exchange, and want to make sure large deposits are not going to be double spent or orphaned
You hold a large amount of cryptocurrency, and want to maintain security and privacy of your funds
You live somewhere with heavy financial/economic restrictions, so access to webwallets, etc is banned outright. So to interact with the network you have to run your own node.
You are a believer in the philosophies behind cryptocurrency, and want to run a node just to help the network grow and remain robust.

This is not an exhaustive list, I'm sure there are more reasons than I have listed. In general it is important that users remain capable of running their own nodes, as otherwise they will have to trust someone else to do so for them.


How can I run Bitcoind -server in "light mode"? Hi! I would like to set up a local wallet at my computer, which runs as a daemon. However, the blockchain takes ages to download and every single day it takes quite a lot of time to update the receiving transactions.

Is there a way to use Bitcoind in a "light mode" and avoid so much cpu/disk usage?

Thanks!

I don't think Simplified Payment Verification (SPV or "light mode") is available in the reference client. There are plans to implement it in the development going on in the discussion email list though.

However, you could download the source code for MultiBit and then use that as a starting point for your own daemon. Alternatively, just use the underlying BitcoinJ library which offers some example tools that probably do what you want right out of the box.