Why is the probability of finding a winning nonce exactly the same for a new header and a header where you've already tried 1 billion nonces? I'm referring to this question: When do miners stop waiting for new transactions?

More specifically, this statement from the top answer:

"suppose you have a block header h1 on which you have already tried a billion nonce values, and a header h2 which has just been generated and on which no nonces have been tried yet. If you have the choice as to which one to hash next, which should you choose, for the greatest chance of finding a winning nonce? The answer is, it makes no difference - they both have exactly the same probability. So there is no harm in switching to h2"

I would have thought that the probability would be slightly higher for the first block (h1) as there are 1 billion nonces that you know do not succeed, i.e. fewer winning possibilities.

Complete newbie here and to the bitcoin world so apologies if I'm missing something obvious.

I would have thought that the probability would be slightly higher for the first block (h1) as there are 1 billion nonces that you know do not succeed, i.e. fewer winning possibilities.

For every computation, you have the same probability of generating a valid block hash. Nothing you can do will change this, even if you try every possible nonce value for a given header. Nothing about what you find while testing nonces will tell you anything about what the next nonce value will return as output. Each guess does not get you ‘closer to the goal’, it is just a random chance.

Think of it like this:

You have a six-sided die (numbered 1 to 6) that you know is fairly weighted. If you roll a 1, you get to make the next block! Every other roll does nothing.
You roll the die ten times, and don’t get a 1 on any of the rolls.
Now, on your eleventh roll, you are given the option to switch dice. You can replace the one you were rolling, with a new one that is otherwise the same (also six-sided, printed with 1−6, fairly weighted). Your choice.

What will give you the better odds of rolling a 1? The answer is: it doesn’t matter. The fact that the first die didn’t roll a 1 yet doesn’t influence what the next roll will be. The same goes for the replacement die. Just because it hasn’t been rolled yet, doesn’t make it any more likely to be a 1 (or any other number).


BFL 7GH Jalapeno suddenly trips circuit breaker, what can I do? After chugging along just fine (though never at full advertised GHps always 6.5 instead of 7), my Butterfly Labs jalapeno suddenly started to persistently trip the circuit breaker all of a sudden, even if I plug it into a plug in another room, on another circuit.
The thing that seems to be important is that when the USB cable is plugged into the PC it trips the circuit and not when it is just pulling power from the outlet with no USB connection.
It was not overheating (Around 115F), and up until last night it never happened - now it happens no matter what..

I had one Jalapeno power supply die on me, perhaps you can source a replacement?  12V seems OK, but make sure it's rated for the amps.


What exactly does redeem in the context of bitcon mean? In this website, it says "The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer."

I looked all over the internet, and could find no clear explanation of what redeem is in the context of bitcoin. Is it the receiver of the bitcoin?

In Bitcoin terms, "redeem" means to claim an unspent transaction output (UTXO) by listing it as an input of a new transaction.

All a Bitcoin transaction really does is claim ownership of one or more UTXOs, and combine their value into one or more new UTXOs.  To do this, it must prove ownership of the UTXOs being used as inputs.  Each UTXO has a script that defines a condition that must be met in order to use it as an input (scriptPubKey or encumbrance script).  To redeem, you must supply a corresponding script that meets that condition (scriptSig or redeem script).

The website you refer to is an improvement proposal (that has already been implemented) where instead of specifying a script in a UTXO, you specify a hash of a script.  This means that a transaction that claims UTXO needs to specify both the script that meets the condition, and the original script from which the hash was produced.


Mining Hardware lifespan is less than a year? I have been exploring mining hardware at http://mining.thegenesisblock.com today.  No matter what hardware I look at, all of them are making no profit by Oct 2014.

How is this a good purchase?  I assume the answer is that if you spend 5K on hardware and electricity and make 60K back in bitcoin in a years time, then you can consider it a good purchase (even though the hardware is now losing money).

Also, how is this model sustainable?  Will new hardware be developed fast enough to continue mining past the middle of 2014?  Am I reading too much into that prediction tool?

Mining really can be a zero sum game. The profitability factor though is the potential of increase in Bitcoin value. If you start mining now and begin start to mine less and less, you may only come out even. Hold those coins long enough, and you may be able to make a profit if the value of Bitcoin continues to increase.

If you throw all this money at ASIC hardware and it becomes useless in a year, it's trash. There is no use for out of date ASICS. Invest into GPUs and CPUS, in a year, you can at least sell the hardware.

Personally, I feel as though there is more potential for growth in GPU and CPU coins such as Litecoin and Primecoin/Quark. You can mine these coins and transfer to Bitcoin if that feels right for you. I started mining Litecoin in June with the assumption that I would break even around January. The value of Litecoin skyrocketed and the whole deal became very profitable. It all comes down to whether or not you believe cryptocurrencies will continue to grow in value. I believe that cryptos are just in their infancy, and things are just getting started. You might also be better off simply buying coins.


Can Armory be used for mining? Can Armory be used for mining?
I hear it is a wallet, but as it downloads the whole blockchain anyway should not you be able to mine with it, too?

Armory uses Bitcoin Core to download blocks and other basic functionality. Bitcoin Core is what is normally used for mining so that's what you'd be using. Armory does not add anything useful for mining. When you mine you can send the mining income to an Armory wallet without Armory taking part in the mining process.


How to handle multiple transactions from the same account(address)? I am new to bitcoin so please bear my question. To understand the IN's and OUT's of this crypto world, i am creating a dummy bank to have a better understanding of the system.

So I have a bitcoin core running in my local system. Now for each user in the system I create an account for them using the getaccountaddress.

So let us consider I have one account named A having a deposit of 10 BTC. Now, suppose the user A wish to withdraw 1BTC from his account so, I first find all unspent transactions filter it by address associated by account A and send this 1BTC to user A. Now as I understand that the bitcoin cannot be partially spent so the remaining change will go to a change address so I provided account A's address from which the transaction was created.

Now my problem is that if the user again wishes to withdraw, I cannot find any unspent transaction since the change is not yet received immediately and will only be available when the transaction is confirmed.
So what is better way to handle this? What is a typical standard to handle such situation? How does wallet like Electrum works as I can see that I can send multiple transactions one after another.

Confirmation concept is generally useful for the counterparty to be sure that the transaction through which he has received the BTC cannot be reversed. Nothing stops you from creating a new transaction referencing the outpoints (txid and n) of the transaction through which you just spent your 1BTC, if you do not plan on changing the previously broadcasted transaction by say a higher fee. Either both transactions can get mined in the single block, or the second transaction can get mined in block after the first transaction has been mined.


Who/What generates Bitcoin Hashes to be mined? Bitcoin miners decrypt hashes, but who or what encrypts them in the first place? After all, something must have encrypted it so that miners could find it.

"Decrypting hashes" is not really a correct way to describe the calculation, and nobody "encrypts" them, which is probably why you could find no information on this notion.

The hashes that miners calculate are based on all the transactions on the network, metadata and previous block hashes.


Miner seems to be stuck at receiving new blocks I have two laptops cranking hashes for pooled mining. My Mac is set up correctly, and I see the (yay!!!) messages pretty often from the minerd.exe output.

However, the PC I have cranking never seems to get the (yay!!!) message. It keeps on doing hashes and then receiving the "Longpoll detected new block" message. I even downloaded the Litecoin-Qt wallet, let it synchronize with the system, and placed the Minerd and mining_proxy EXE files next to the Litecoin-Qt in hopes that it would be able to access the longest chain due to the effort of the Litecoin wallet's synching.

I followed the steps for a PC in Litecoin LTC mining guide, CPU.

How can I make it work?

Try instead GPU mining with Cgminer 3.7.2 it has always worked well for me. Using CPU on a machine only, is really not worth it.


ripple migration issues i had an old ripple account that has stayed untouched for a long time,  ripple advise that you need to migrate it to gatehub, this process does not work, i have tried to transfer it another wallet and it advised my pass phrase is incorrect, it can be only one of two passwords that i used for all online stuff at the time.

Is there away to re set the pass phrase i still have the walets secert key, i see some old links from 2013 -2015 on just setting up  new account with the secert key, but none of the new walets offer the option to add tge key on registration.

Cany anyone help?

If you have the secret, you can forget about the old wallet. Use the secret in any XRP wallet that accepts a secret. Gatehub does. The old Ripple desktop wallet does. Jatchili's minimal client does.


Is the a library for generating signatures and transactions for scrypt coins? I'm looking for a library similar to this bitcoin one but that works with scrypt based coins.

The use of scrypt vs SHA256 has an impact on proof of work but no impact on the signature scheme or transaction structures. The only thing that should impact you when using this library is the address prefix that differs with altcoins.

The standard address prefix for Bitcoin is 0. For Dogecoin for example it's 30. So you could reuse that same library and generate valid Dogecoin transactions just by passing that additional parameter to the pubtoaddr function like so:

pub = pubtoaddr(pub, 30)


Why is Bitcoin defined as having 8 decimal places? At the protocol level bitcoins don't actually exists, but rather base units (recently called “satoshis”). Bitcoins are defined as 108 base units, meaning that for a 50 BTC mining reward, you are actually earning 5 000 000 000 units.

So, why was 108 chosen as the value of one bitcoin relative to the base unit?

When developing Bitcoin, Satoshi had already come with the idea that no more than 21 million of them will ever be made. However, there was an unsolved issue: how to accomodate all bitcoins in case it was actually used as a worldwide currency? Comparing to the current (2008?) world's M1 supply, it was determined that 8 decimal places was enough to cover the supply and still have the smallest division smaller than enough for daily usage.1

It's also worth noting that this decision means the total Bitcoin supply is approximately 250.89, which means it's smaller than the maximum value for a 64-bit integer (263-1), and smaller than the first integer that can't be exactly represented in a double-precision floating-point number (253 + 1), so that standard programming languages can deal with Bitcoin amounts without requiring custom implementations or dealing with overflowing.2

Ray Dillinger's response to: Why 1BTC should equal 10^8 satoshi ?
Satoshi’s Genius: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets


Transaction Questions Here is a scenario someone posed to me and I'd like to check the answer:

If I send a transaction that gets orphaned and I then issue another transaction from the same address (but include a fee) and this second transaction gets added to the block chain (I have >no reason to see why it wouldn't....there's a good chance other nodes wouldn't even know >about the orphaned block as it may not have been relayed. Can the first transaction be put in a block? When does the transaction get time stamped?
I presumed the answer is that the original transaction will become invalid as it would not be confirmable.  Also, during the orphaned period, the private key could be imported to another >wallet and another transaction issued from that address (AFAIK, no wallet will intentionally >let you construct double spends).

Their assumption is correct: if you send a transaction that gets orphaned, and then send another transaction that goes into the block, the other transaction automatically becomes invalid.

Transactions don't have a timestamp embedded, so miners don't have a way of knowing which transaction came first. They just include the one that first reaches them, which in your scenario will be the second one.


Transactions are not guaranted to be validated I have read some posts about transactions never to be confirmed, but those post implied small transfers with no fees.

In my case my two transactions have something like 0.000428 BTC of fee.

I don't know if the fee is too small. I have not chosen, it was my wallet Coinmoni that did it for me.

Anyway after almost 3 days without the 2 transactions being confirmed... my first impression is that there is a flaw in the Bitcoin system. What is the guarantee the transaction ever happens ?

No guarantee. Am I wrong ? It's up to miners to choose the block they will compute.

What's the community thinking about transfers not being validated ? Isn't it a problem if Bitcoin really wants to become a public payment method, if transfer/transactions are not guaranted to be validated ?

When you broadcast a transaction, to get a confirmation you're bidding for blockchain space, a limited good. Since blocks currently supply only one megabyte of space, miners maximize their profit by selecting transaction in order of fee rate, i.e. the number of satoshis offered to the miners per byte of transaction size. (Unless there is an additional out-of-band payment that skews selection.) The amount of value transferred has no direct influence on the selection, and there is no guarantee for inclusion, the transaction selection is the miner's prerogative.

It is however your prerogative to increase your bid by updating and re-broadcasting your transaction.

Yes, this is a problem to some degree which is why there are protocol upgrades (e.g. SegWit, Schnorr Signatures, Signature Aggregation, Lightning Network)  waiting to be activated (or in the making) that will provide a larger throughput.


MimbleWimble on Bitcoin As you know the Litecoin implementation of MimbleWimble on extensions blocks is already running on testnet. They will go mainnet in a year. I think this could be a great improvement for Bitcoin. We could use Bitcoin for private transactions when required, no need of coin mixers or Monero anymore. Exchanges like Coinbase will not delist Bitcoin as they already have ZCash which have public and private transactions too.
In the rare case there is a hidden inflation bug, new coins created in the extension block can't infiltrate the canonical chain because the amounts are public, so the bug would be detected sooner or later when someone can't send back his coins to the canonical chain.
The developer has said he's going to write a BIP and make a pull request to Bitcoin. What are the chances it's approved?
Regards

There is zero chance of it being used in Bitcoin.
There is prior incidents to gain wisdom from. Before zcash existed as an altcoin, zcoin was an implementation of a similar concept which people rallied behind and tried to ham fist into Bitcoin. It's essential, it's a mandatory, it's my right to be private! If you don't put zcoin into Bitcoin you are the manifestation of the devil himself, brought to destroy the fabric of society!
Unfortunately whenever things like this have been social pressured into existence for reasons of perceived valor, it has lead to problems. In the case of zcoin, it was later discovered that the implementation of zcoin slated for use in Bitcoin had an unbounded, invisible inflation bug which would have instantly ended the currency.
Bitcoin survives by being conservative with changes, not grabbing onto everything shiny.


Is it a 51% attack or a >50% attack? Is it 51% attack or 50.0000...1% attack?

Bitcoin is getting to a point where 1% is a lot of hashing power...

My understanding is >50% due to the nature of the protocol.

When performing a 51% attack, you will need to find new blocks faster than the remainder of the network combined. This way, your block chain will become the longest and clients will consider it the main chain.

Theoretically, this is achieved (on long term) when you have >50% of the hash power.

But as we know, a lot of luck is involved in mining. It's possible that someone with 55% or even 60% of the total hash power will only succeed in his 51% attack after many weeks because he has bad luck. (Note that with >50%, statistically you will always succeed on long term.) But it is also possible that someone with less than 50% can succeed on short term.


What is the best way to send money to a friend overseas using a Bitcoin ATM? I have a close friend living overseas who I wanted to send money to. They suggested using a Bitcoin ATM instead of other methods. What is the suggested best way or method for me to use this method?

Ask your friend to send you their Bitcoin receiving address - they should use their Bitcoin-Wallet to create and show them a new receiving address for this transaction. They can then send you the Bitcoin-address in email etc. It will look something like one of the following examples (don't use these):
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq or
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy or
1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
They can instead send you a QR-barcode that you might be able to scan into the Bitcoin machine. This is probably less prone to mistakes. If you make a mistake the money is lost - bitcoin transactions cannot be undone, cancelled, or reversed.
At the Bitcoin machine, make sure it is not creating a new wallet or a new account with some business but is instead sending the purchased BTC directly to an address of your choice. The details depend on the make and model of Bitcoin machine. You may have to choose some specific options on the machine. Enter or scan your friend's address as the receiving address and double-check it. Make a note of any transaction-ID and/or keep any paper receipt.


How does number of transactions in the block affect it's mining time? Does number of transactions in the block affect it's mining time?

How and why?

The number of transaction in a block negligibly effects the mining time. The only effect is that more computations need to be done to calculate the merkle root during block construction, but that is a very small fraction of the number of calculations needed to be done during mining itself. Mining only hashes a fixed amount of data so including more or less transactions does not really make a difference.


Paid $4.26 on a $133 transfer - why unconfirmed? I sent money to myself from a Bitpay wallet (using send Max) to a Cashapp wallet.
Transaction id -  577b3fe1e372e2375bcfbb2c666cdc74fa766fd022592040a539154c9ff7d820
https://www.blockchain.com/btc/tx/577b3fe1e372e2375bcfbb2c666cdc74fa766fd022592040a539154c9ff7d820
Why 20 hours unconfirmed and is there any way to get this unstuck considering the 2 web wallets I use?

I'm predicting that this transaction will confirm in less than a week considering its relative feerate.

Paid $4.26 on a $133 transfer - why unconfirmed?

Because the input addresses are 1... addresses instead of the newer SegWit addresses bc1. By switching to a native SegWit addresses you may enjoy faster confirmation times at any constant feerate level.
The destination address is 3... which means probably it's a SegWit address too. However, 3... addresses pay slightly higher fees than bc1 addresses so bc1 addresses are suggested whenever possible. (Still, the suggested feerate difference between 1... and 3... addresses will make a considerable difference, you'll notice it when you spend from your destination address)


Armory takes 8 Hours to sync. Is it going to get worse as Bitcoin becomes more popular? I have been experimenting with Bitcoin and I installed Armory wallet. It told me that it would take approximately 8 hours to sync the worldwide ledger.

My question is, as Bitcoin gets more popular, will it take longer to download the ledger?

If so, doesn't this pose a problem - could it get to big to be feasible?

The short answer would be yes, if the chain
becomes bigger it takes more time to download
it.

The more detailed answer would be: there is
plenty of options to make it quicker: for
example you can download already constructed
chain from some trusted source.


Is GPU mining worthwhile for any currency? I've been under the impression that all proof-of-work mining is now done by ASICs.

Then I saw this article, that says,

  "AMD shares are surging with bitcoin because digital currency 'miners' need its graphics cards"

Is there any truth to this?  Or just False News?

There are countless digital currencies in existence; every day new ones appear, are pre-released; ICO'd, or are ninja launched.

Bitcoin is SHA-256, which renders mining using CPUs and GPUs pointless because ASIC processors have been engineered; chips which serve only one purpose; that is to compute/solve/hash SHA-256, and because they are engineered to do only that; they are exponentially more efficient in doing so.

GPUs on the other hand are used to mine coins both by hobbyist miners and large scale GPU farms.

But they aren't mining Bitcoin; or any other SHA-256; they are mining coins either with new POW (Proof of Work) algorithms; or POW algorithms for which no ASICs have yet to be engineered (or are simply not public/available).

For GPU based setups; common algos are X11, X13, X15, Scrypt depending (as ASICs do exist for Scrypt but were not widely adopted); and many others.

You can find a list here: http://bitcoinguide.online/a-list-of-cryptocurrency-algorithms/

If you only have a single GPU; there is really no point whatsoever in using it to mine a currency; unless it's your own clone that you're creating.

You can go on site's like NiceHash and rent mega power; based on bidding per / g/hash t/hash; and jump in and speculate on what coin may or may not be profitable to mine. One GPU simply wont cut it.

Or you could build GPU mining rigs; using a simple steel frame; a low end CPU processor; 4 GB of ram; run Ubuntu off a USB stick; and slap 4 or 5 GPUs on the motherboard using PCI-E Risers.  You'll need a decent 1300w or more PSU; depending on the algo; and you must be network and code savvy; as it's mostly all still command line driven.

If you do so; expect to lose money the first year; it's still the wild west; and the only way to learn it is in the trenches.

And to add; yes; AMD shares have been volatile due to alt-coin news and releases. As have prices. Cards, such as an AMD R9 280x; one of the most popular first gen cards at the time Alt Coins came crashing onto the scene; skyrocketed in price from $200 to $500 or more on all sites; including Amazon. As did all components; PSUs, etc.

Then; they would crash with the market; people would burn out; the secondary market became flooded with people ripping their rigs apart and selling off the pieces; and then repeat-- new coin comes out; it becomes a huge rally, and the card prices would jump back up... sometimes doubling, tripling in price in days... People made money of that as well; simply buying GPUs on the crashes and selling on the rally's.

I often joked that Bitcoin; and later the alt-coin clones which appeared in hoards were invented either by the Power Companies; or the Chip/Wafer manufacturers.


Generating differnet addresses from same public key? There's a gap in my understanding regarding the generation, via hashing, of bitcoin addresses. (I'm quoting from Antonoplous  below for convenience, but I have consulted multiple other sources.)

According to Antonpolous:

  "The bitcoin address is derived from the public key through the use of
  one-way cryptographic hashing. (Antonpolous, 2014:71)"

My understanding of public keys is that they do not change once generated from a private key (via ECDSA multiplication):

  "Because the generator point is always the same for all bitcoin users,
  a private key k multiplied with G will always result in the same
  public key K.(Antonpolous, 2014:68)"

Best practice regarding bitcoin addresses recommends that:

  "a unique address should be used for each transaction. Most Bitcoin
  software and websites will help with this by generating a brand new
  address each time you create an invoice or payment request.
  (Antonpolous, 2014:188)"

I understand that performing a hash function on the same data will always produce the same result (digest):

  "For any specific input, the resulting hash will always be the same
  and can be easily calculated and verified by anyone implementing the
  same hash algorithm." (Antonpolous, 2014:188).

Given all of the above, my question is, how can different addresses be generated from the same, unchanging input, namely the public key?

Is it the double-hashing (SHA256 + RIPEMD160)? Is it the address pool? Is it due to deterministic wallets? The answer is probably simple and staring me in the face, but I can't see it. Thanks for any clarification.

For some reason you came to the conclusion that you can just derive multiple addresses from a single public key, but the quoted text doesn't say that. It says that the public key is uniquely generated from the private key (by multiplying the curve generator G by a random 256-bit number which is the private key). It also says that the address is derived from the public key by hashing it (RIPEMD160 & SHA256). Finally it says that it's a good idea to use a different address every time.

That doesn't mean you generate multiple addresses from the same public key. Each time you have to generate a new private key, then public key from that private key and finally the address from the public key.


What criteria should be taken into account when selecting nodes to create new lightning channels with? Alex Bosworth recently pointed out:

  I see people connect to a "well connected" node on LN and by that they mean they connect to a node with lots of channels. The number of channels is actually a contra-indicator of a node's ability to route. Good routers curate and balance. Bad routers spam the open channel button. [Emphasis added]

What criteria should be kept in mind when evaluating nodes while opening new channels on the lightning network?

I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.

There are several kind of information we can look at (my autopilot currently only looks at the first ones):

Network topology:

How can I increase my centrality (e.g. by connecting to central nodes)
How can I increase my probability to have well funded routes by connecting to points where a lot of liquidity is floating around
Improve the network topology by increasing the amount of triangles
Geography: It is likely that you pay to services where you live and therefor you might want to connect to nodes that have a similar geoip as yours.

Node Provenance / properties:

age of Node (seen by oldest channels)
age of channels (seen by the blockheight of funding transactions)
uptime of the node (can be tracked via the gossip messages and the gossip store)
Routing fees of the node
Reliability of the node to forward payments (can be tracked by doing fake 1 satoshi payments to yourself over different routes)

most of the stuff that I mentioned here has been taken from my blog article about autopilots. In general I hope that better autopilots will emerge because I think this problem will be hard to decide by humans without investing a lot of time.

Finally another strategy could be to create routing tables in a similar way as the border gateway protocol does on top of IP. In that case nodes would share partial information about the channel balance so that we would have a better overview of where liquidity is missing.


Can ASIC or FPGA boards be used to mine Litecoin? I know that Litecoin was designed to be mined with a CPU but then someone figured out how to mine it with a GPU.

Has anyone figure out how to mine Litecoin with an ASIC or FPGA boards, and if not is it conceivably possible? (and by that I mean would it be more effective)

Yes, there are designs for Litecoin mining FPGA bitstreams, but they are not very efficient currently. ASICs are much more efficient and if anyone finds it lucrative to invest in development of Litecoin mining ASICs, they will push out GPU mining. (The efficiency ratio between ASIC and GPU will be lower than with Bitcoin though).


-walletnotify on 6 confirmations instead of 1? Pretty straight forward. Right now im using -walletnotify to run some node.js code when i get an incoming transaction and when theres 1 confirmation. However, after reading around, i found out that 1 confirmation is not secure, which now makes me want to execute this confirmation code when theres at least 6 confirmations.

TL;DR, Is there a parameter or an equivalent for -walletnotify to run on N confirmations?

This is not possible with the current version of Bitcoin-Core (0.13.1).

Consider opening a issue (feature request) https://github.com/bitcoin/bitcoin or start implementing it yourself.


How to send bitcoins from an online wallet to a blockchain.info wallet? I bought a small amount of bitcoin. They are in an online wallet. I would like to send them to a more secure wallet, my blockchain.info wallet. I have a few questions about the process.

From the online sending wallet. I must enter my blockchain.info receiving address. Enter the bitcoin amount. Then hit send. Am I missing any steps? Do I need to do anything with private keys or will that be done automatically?

From the receiving blockchain.info wallet. After the bitcoin balance shows up in my wallet, am I required to do anything? Do I need to do anything with private keys? Should I back up the wallet afterwards?

That's all there is to it.  The wallets handle the private keys.

It you have access to the private keys for the online wallets, it is always a good idea to export them and save them in offline storage (not on your computer).  That way, if the online wallet goes away, you can still recover your coins by creating a new wallet and importing the private keys.

If you don't have access to the private keys, a better option would be to create your own wallet (either on your computer or offline on paper).  Send the bitcoins to this wallet instead of an online wallet.  This way you are protected if the online wallet disappears or is hacked.  MultiBit, Electrum and Armory are all good wallets, so pick one that meets your needs.  You can find more information here.


How long does block validation take? Assume a miner receives a new block from a connected peer. Please correct me if I'm wrong: The miner validates the newly received block before using it themself and sending it to their other connected peers. I heard this but it seems to me that it'd be a better strategy to already use the block to mine on top of it because the block header and the proof of work associated with it is very fast to verify and it's highly unlikely someone made a block header with a small hash for an invalid block. So why keep mining on top of the previous block?

How long does this process typically take? What does it depend on? Is it done on specialized mining hardware or on a general-purpose CPU?

Is it correct that the time block validation takes is linear to the block's + witness's size should segwit activate?

Also: How long does it take on average for a block to be propagated through the network? It'd be great if that average is weighted on the receiving miners' hashing powers.

There are several questions here.

  Please correct me if I'm wrong: The miner validates the newly received block before using it themself and sending it to their other connected peers.

Yes and no. Note that by miner we're talking about people who build blocks themselves - that includes solo miners, pool operators, and p2pool users. Hashers that only connect to a pool and perform work are not part of that group.

Miners can - and sometimes do - build a new block before they've fully processed the previous one (even if it's their own), to avoid time not mining. Unfortunately, as they don't yet know which UTXOs are spent in the just-received block, they don't know what follow-up transactions are valid, and thus can't include any new transactions. Because of this, these blocks will be empty apart from the coinbase.

In practice, these miners will have two mechanisms to update the proposed block their hashers are grinding on:

A new best block hash is announced within their own network (or detected on another pool's network - for example by listening to their pool interface, or by an agreemwnt to send each other information). When this happens, all hashers are told to start working on an empty block.
A new block is received through their bitcoind (via the P2P protocol, via the submitblock RPC command for their blocks, or via separate relay networks like FIBRE). bitcoind then builds a new set of valid transaction on top (through the getblocktemplate RPC), and they update their hashers to start working on a block with these blocks.

The assumption is that when (1) happens, the same block will shortly go through (2), and we'll switch from working on an empty block on top to a normal block on top. There was once an incident where this did not happen.

When BIP66 activated, some miners running a BIP66-enabled bitcoind versions were listening in on blocks sent by pre-BIP66 pools. A pre-BIP66 miner produced a non-BIP66-compliant block (wrong version numbers), and BIP66-enabled miners listened in, and started producing empty blocks on top. Of course, their bitcoind never accepted the full block as it was invalid according to the new rules - rules those themselves miners agreed to. The result was a sequence of many empty blocks on top, with many miners building on top of the previous invalid blocks, all of which were not accepted by the network.

So to answer your question:

  So why keep mining on top of the previous block?

Because the new one may be invalid. It's unlikely to happen intentionally due to the costs of mining an invalid block, but it can happen as a result of software or manual bugs. Furthermore, we should not build infrastructure that relies on this not happening - as doing so might over time make such attacks cheaper.

  How long does this process typically take? What does it depend on?

In your process you're only counting block validation. But the whole process consists of everything between (A) the creation of a valid block on the network and (B) hashers switching to building a block on top of it. This includes:

The previous block creator getting the block out to the network. There may be unintentional delays here, or even intentional delays (like a Selfish Mining attack).
The blocks needs to propagate across the network. Normal bitcoind nodes only propagate after full validation, and require bursts of high bandwidth to transfer all blocks. More recent technology like Compact Blocks (BIP152) and FIBRE avoid full resubmission or even waiting until validation completed.
The blocks need to be validated.
A new set of valid transactions on top has to be created.

Validation depends on many factors:

Software version. There are constantly improvements to validation speed.
UTXO cache size. The larger the cache, the less database access is needed to retrieve information about the outputs being spent. As a result, just fetching of inputs can take from a few milliseconds to a few seconds.
Signature cache size and CPU speed. The larger the cache, the more signature validations can be avoided. These validations - depending on the software version and hardware van vary from 0.01ms to 0.6ms per signature (45ms to 2.7s for a block).
Correlation between the memory pool and the new block. If a block contains transactions that a node hasn't seen before, its inputs and signatures are less likely to be cached before.
Bandwidth. Prior to Bitcoin Core 0.13, blocks were always submitted in full between peers, which can cause big spikes at the time a new block is announced.
Network latency. In more isolated parts of the world, even with good bandwidth, the time it takes for a network packet to reach the outside world can be significant. Depending on the protocol, 1 to 3 roundtrips are needed to send a block. If the latency between two peers is 200ms, that can already mean 1.2s wasted on going back and forth.
Number of connections. If a node has many connections, it will try to broadcast a new block simultaneously to all, causing a spike of work of network activity. This can be too much for the CPU or network hardware or bandwidth to handle, causing slow downs when many connections exists.

The time to construct a new block mostly depends on software version. In older versions it was up to a few seconds, but lately is has been reduced to tens of milliseconds.

  Is it done on specialized mining hardware or on a general-purpose CPU?

As far as I know, no custom hardware exists for block validation or block construction.

  Is it correct that the time block validation takes is linear to the block's + witness's size should segwit activate?

Mostly. There exists an inefficiency in the currently signature hashing algorithm that can be O(n^2) in the size of transactions. This can result in single transactions that take minutes to just compute the signature hash. This is fixed in BIP144, which is always used inside SegWit transaction inputs, making it O(n) at worst (less than 10ms for a block in the worst case on common hardware).

Longer term, there are other factors that play, like the size of the UTXO set. If this would grow to multiple gigabytes, and not fit in typical memory caches, the UTXO fetch time for validation could go up dramatically.

  Also: How long does it take on average for a block to be propagated through the network? It'd be great if that average is weighted on the receiving miners' hashing powers.

That's complicated. It's certainly not proportional to hashing speed, but more related to network topology and used technology. The FIBRE website has some statistics, but often transfers in less than 20ms more than the minimum theoretical network latency (speed of light across long connections) across the globe. This is only possible by being a private network that assumes its participants will not engage in DoS attacks on the network. The public network is much more robust, but often takes many seconds to propagate a block to large portions of nodes, and dozens of seconds to reach less connected nodes.


How is the amount of proof-of-work invested in a chain calculated? The bitcoin whitepaper (page 3) states

  The majority
  decision is represented by the longest chain, which has the greatest proof-of-work effort invested
  in it.

I could not find how exactly this difficulty is calculated.

Is it the sum of prefix zeros of the nonces of each block?

I found this answer but it is too short for me to understand.

Work is calculated as work = 2^256 / block_target, as stated in the linked answer, which is the minimum hash value that counts as a valid proof-of-work (note this only changes every 2016 blocks). The source code for this is src/chain.cpp L#121. The total chain work is the sum of work for all blocks in the chain, and is calculated here: src/validation.cpp L#3713. So to visualize, the lower the block target, the more work has been done.

Example

Block 0 target: 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Block 1 target:
00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Block 0: work = (2^256) / <block 0 hash> = 4.295 × 10^9
Block 1: work = (2^256) / <block 1 hash> = 4.295 × 10^9

You can see that they have both done the same amount of work. In case of a tie, the following rules apply, see https://bitcoin.stackexchange.com/a/37275/60443

Which one was received first? (This can be different for different clients, which is why the previous rule is applied first.)
Which one has a larger pointer address? (This is largely random, and different for different clients.)


What is the longest blockchain fork that has been orphaned to date? The orphaned blocks view from BlockChain.info shows a recent fork of the blockchain (starting with block 173,928) that went four blocks long before being orphaned.

Other than the controlled rewind following the Value Overflow bug in August 2010 in which 53 blocks were orphaned, is there a fork of blocks orphaned as long or longer than this one that occurred at 173,928?

Short answer: 4 [Prior to the March 12, 2013 fork]

The Value Overflow incident seems to be the longest ever blockchain split. The problem with blockchain forks is that once they are resolved the only trace they leave is a log entry.

To reconstruct the following I used the printblocktree output that theymos gave me in this question and the information from Blockchain.info.

As far as I can see from the printblocktree there have been 90 blockchain forks observed by theymos in the blockchainrange [90392-189512].
This dataset has the following forks:

1x block length 4 (starting from block 174161)
1x block length 3 (starting from block 174120)
4x block length 2 (starting from blocks 93669, 174233, 179217 and 179639)
87x block length 1 (starting from blocks 90392, 90676, 90858, 91405, 92094, 93047, 93088, 93619, 93642, 93669, 93670, 93671, 93855, 94671, 98529, 99365, 100740, 101902, 102674, 105401, 109912, 117103, 118553, 120406, 123583, 128501, 130077, 130200, 155180, 157929, 161673, 162257, 163959, 165439, 165519, 166890, 167283, 167620, 167742, 167863, 168920, 169517, 171064, 173494, 174102, 174104, 174121, 174174, 174182, 174185, 174187, 174232, 174242, 174291, 174307, 174313, 174330, 174343, 174414, 174452, 174531, 174593, 174605, 175998, 176210, 176478, 177854, 178119, 178293, 179791, 179890, 180143, 181230, 181591, 181618, 182210, 182321, 183193, 183405, 183500, 183519, 184932, 186561, 187866, 188347, 188682 and 189512)

Blockchain.info does have quite a few more orphans in their database, apparently because they connect to a lot more nodes, but their history does not go back as far as theymos' printblocktree.
The first blockchain fork that bitcoin.info observed was based on block 142257 since then we observed 540 forks:

2x block length 4 (starting from blocks 174161 and 173927)
4x block length 3 (starting from blocks 174120, 174056, 174050 and 173956)
14x block length 2 (starting from blocks 183873, 179639, 179217, 176924, 175847, 175226, 174233, 174093, 173988, 173985, 173691, 170059, 165518 and 155180)
520x block length 1 (far too many to put them here...)

The problem is quite evident: while both see forks, theymos' set has a smaller view of the network and misses or misinterprets forks (the one starting from 155180 is marked as a length 1 fork in the first results and as a length 2 in the second). We cannot be sure that blockchain.info catches all of the forks but we can be pretty certain that there was no fork longer than 4, as the fork would survive longer and would be seen by more nodes.


I just encountered the same problem and the solution is almost stupid. Since the hint is not found elsewhere, I'd add my two cents in case others stepped upon the same trap.

It turns out that, besides the usual reasons related to time (e.g., time lock hasn't expired, the sequence number is not properly set etc.), trying to spend an unconfirmed UTXO also causes non-final error. I didn't dig into the source code to see why this happens, but the misleading error message cost me a good afternoon.

Why would you ever attempt to spend unconfirmed outputs? Well, when you're busy testing things out and are gradually losing ur patience...


Could LN wallets be seamless? Currently, the funds deposited in a payment channel cannot be sent on-chain without closing the channel. Similarly, the user must open a brand new channel in order to deposit some on-chain funds into LN.

Is it possible to make a LN wallet seamless, so that the user could be freed from dealing with hassles like channel opening/closing?

No, that is not possible. The opening and closing of channels by confirming funding and closing transactions represents the act of securing and delivering of the channel capacity and balance respectively.

The 2-of-2 multi-sig from the funding channel represents the total channel capacity. During the lifetime of the channel, this multi-sig must remain unspent, so that the spending transaction which is eventually confirmed during channel close can be updated during the channel lifetime.

Since no coins can be created, the (funding) input cannot be more than the total of closing transactions outputs, whose amounts represent the last channel balance.

There are proposals to "spend" this funding output together with additional inputs/outputs to an updated funding output to update channel capacities.
See channel "splicing" on this topic.


Why was transaction malleability fix required for Lightning network? Transaction malleability is that TXID can be changed modifying the signature slightly without the private key. To implement Lightning Network, it was required to fix the malleability.

However, I thought that we just wait for 1 confirmation that we create an opening transaction, which is 2 of 2 Multisig, in order to open a channel.

After researching Lightning network protocol, I kind of found out that before broadcasting the opening transaction, we have to create a commitment transaction that needs the TXID of the opening transaction, and we have to keep it to claim. If the TXID is changed, the commitment transaction won’t be valid. So we needed to fix transaction malleability to keep the commitment transaction valid.

Is this correct? If not, please educate me.

Alice creates a multisig transaction sending 100btc to a shared Alice-Bob output–one that requires both signatures–and signs it. We’ll call this transaction Tx0. And she only reveals Tx0 to Bob after:

Alice and Bob each sign a timelocked transaction for 30 days from now, sending 100btc back to Alice. This is not committed to the blockchain, and opens a “channel” between them.

Uncommitted transaction has dependency over Tx0. After Alice reveals Tx0 to Bob, if Bob successfully changes the transaction hash for Tx0 on blockchain, then uncommitted transaction will become invalid and Alice will not be able to claim 100btc back.

If, in addition to requiring the refund Tx, Alice also requires Bob to sign Tx0 before she does so that only she can submit Tx0 to the blockchain, this attack would not work.


Do all block have to be verified every time a new block is broadcasted? I did a presentation for my office and during the presentation I was asked a question that I was not prepared for. It's a more technical question from my perspective, but someone here might already know the answer.

We know that every 10 min a block is created. And a new block has information of the previous block along with its findings and submitted to the net to be verified.

My question is when a pool or an individual miner is doing the verification, do they verify all the transactions starting from Genesis block till the most recent one?

And this goes on after each block is verified. Meaning every new block that needs verification needs to be verified along with all the previous transactions starting from the Genesis block?

TL;DR: Each block only needs to be verified once. Upon receiving a new block, only the reference to the parent and the validity of the new block need to be checked.

When one gets started with Bitcoin, the client or mining software will download and verify the blockchain. During this synchronization, each block starting from the genesis block will be verified by the client. This is only necessary once for each block, because new blocks always reference the hash of the preceeding block.

I.e. when you are trying to verify Block 5, it will contain the hash of it's parent, Block 4. As your client has already verified that Block 4 is valid, and if the hash featured in the new Block 5 matches the known hash of Block 4, it can go straight ahead and only check whether the new Block 5 is valid.


Orphaned (non referenced) blocks list Orphan block is a block that doesn't have a known parent in the
longest block chain.

As I understand, this mean that orphaned block does not have a reference on it as "previous block hash" in any newest block. It is correct?

If yes, I make some research and does not understand why I get some strange results.

So, I extract all block hashes from raw dat files. Then I extract all "previous block hash" data from raw dat files. As a result I've got 2 arrays: block hashes (array A) and parent references (array B). Then if I subtract B from A, I would get a list of orphaned blocks.

Is it right way to get orphaned block list, or not?

P.S. I get this results after parsing dat files from blk00000.dat to blk00953.dat (I chose two blocks from the compiled list):

000000000000000003D57B69D1AC77F64287C893C16ADBC1816C6D7386CCC3C0 – orphaned
0000000000000000011523D7477DD274B7E0DCC2C616B2E2F584FFDEC20237D3 - main chain

main chain and orphaned are the status based on block explorer sites.

On this two blocks does not any reference as "previous" in raw dat files. I'am confused – "why?"

As a result I've got 2 arrays: block hashes (array A) and parent references (array B). Then if I subtract B from A, I would get a list of orphaned blocks.

No, doing that will get you a list of stale blocks (which are commonly referred to as orphaned blocks). What you are doing is getting all blocks which are not parents of anything, not blocks which do not have parents.

000000000000000003D57B69D1AC77F64287C893C16ADBC1816C6D7386CCC3C0 – orphaned

The term "orphaned" here means that the block does not have any children. This is the second meaning of the term "orphaned block". This result is expected since you are removing from your list of block hashes the list of parent blocks, and this block is not a parent.

0000000000000000011523D7477DD274B7E0DCC2C616B2E2F584FFDEC20237D3 - main chain

This block is in the main chain. It is probably in your list because that is what your node was synced up to and this was its most recent block.


What is current size of various databases in Bitcoin Core as of July 2014? This question is related to question: What is the database for?

What is size in MB of:

blockchain itsef - blocks/blk*.dat
blocks/index/*
chainstate/*
blocks/rev*.dat

Is the size of chainstate and index proportional to blockchain size?

Only the size of the blockchain itself is the same for everybody. You can find graphs that show this size, for example Blockchain Size.

All the other files you mentioned are databases and indexes that your specific client uses to find blocks in the blockchain, or to keep track of transactions or unspent outputs. The sizes of these files are client-specific.


transfer Bitcoin without synchronizing Bitcoin core I installed Bitcoin core recently but its not synchronizing right now. I sent one address from file menu like this below to one of my friend and he is send me some Bitcoin:

13BuBwcQM2WwedYzqkccovjYYPKBAc6RWE

The problem is that I haven't enough storage in my PC to download all of the data so I can't synchronize my bit-coin core and it shows 0.00 balance. I have another Bitcoin wallet in https://blockchain.info site

How I can send my Bitcoin to my new wallet?

If I uninstalled my Bitcoin core wallet, will my bit coin be lost?

The good (or bad) news is that your friends hasn't sent you any bitcoins to address 13BuBwcQM2WwedYzqkccovjYYPKBAc6RWE yet so ask him not to do so until you configure your account to blockchain.info or another online wallet.

Before you proceed with deleting your local wallet, keep the wallet.dat file so you will be able to restore it later on if needed.


Will my bitcoin wallet take prohibitively long to sync as daily transaction volumes grow? I'm using Bitcoin-qt on Mac and it's been a few weeks since I last fired it up, so it's doing a sync. I've waited a few hours now, despite being on powerful hardware and a fibre connection to the web.

If I understand it correctly, the sync involves some processing for every Bitcoin transaction performed globally. In the bright future of Bitcoin, when people are buying Mars bars with them, won't the sync be prohibitively slow due to sheer volume?

Or are we hoping Moore's law will offset this growth?

The points mentioned in this answer apply here. The key points are:

End users won't be expected to run full nodes such as bitcoin-qt, but rather lightweight clients such as Multibit or Electrum.
Not all Bitcoin payments need to take the form of Bitcoin transactions; most will probably take some form of trustless, instant, off-the-chain Bitcoin payments


Are there any non-monetary uses for the blockchain, or the Bitcoin protocol generally? After reading "Have there been attempts at a Bitcoin-powered general purpose database?", I'm wondering if any other uses have been made (or proposed) of the blockchain and Bitcoin protocol that aren't solely about financial transactions (and directly related activities like mining)?

(Perhaps something similar to Bitmessage, but using Bitcoin itself rather than simply taking inspiration from it.)

Proof of Existence is a good example of innovative use of Bitcoin network. The idea is as follows:

  use our service to anonymously and securely store an online distributed proof of existence for any document. Your documents are NOT stored in our database or in the Bitcoin blockchain, so you don't have to worry about your data being accessed by others.

More details:
http://www.proofofexistence.com/about


How do I know how much each address own in a wallet? My wallet has 3 address. One main address is shared with my other computer. The other addresses are not.

Does money belong to a specific address or to a whole wallet? What happen if I send money to one of my own addresses?

What happen if I delete some of the addresses?

Technically, bitcoins aren't sent to a wallet.

The Bitcoin blockchain works as a ledger.  A "wallet" simply holds the keys that allow you to spend funds.

If you are simply asking how to monitor balances for certain addresses, there are third party services such as BTCBalance.net which make this possible.


Lightning payment between two nodes I'm struggling to work out how I can setup a channel between two lightning nodes so that I can send a single payment from one node to the other.

I have set up two separate c-lightning nodes connected to two separate bitcoind testnet nodes.

The steps I've taken are:

Node 1 - lightning-cli connect node2id
Node 2 - lightning-cli connect node1id
Node 1 - lightning-cli fundchannel node2-channelid 10000
Node 2 - lightning-cli fundchannel node1-channelid 10000 (fails with "Peer already CHANNELD_AWAITING_LOCKIN")
Node 2 - lightning-cli invoice 1000 i1 i1 (fails with "No channels have sufficient incoming capacity")

How can I set up two lightning nodes so that I can send payments from one to the other? It seems like only the first node can fund the channel (I have read there is work in progress to allow dual funded channels but can't say I completely grasp that). But then it seems as if the channel is only funded from one side there's no way payments can be made?

They payment is failing because you have opened a channel where node 1 has 10000 sat, and node 2 has 0 sat, and then you are trying to make node 2 pay node 1.

From what I understand, in point 4 you are attempting to have node 2 ‘add funds’ to the channel you opened in step 3. This is not how a lightning channel works: a lightning channel is a bitcoin UTXO, and you cannot ‘add bitcoins’ to an already existing UTXO. Each channel is defined when it is created, and then resolved when closed (the appropriate balance is sent to each participant).

Considering your setup, you can make a payment from node 1 to node 2. Once that is done, you’ll be able to make payments from node 2 back to node 1 (until the whole balance is pushed back to one side).

What you could also do to achieve a similar result is opening a new channel from node 2 to node 1. I’m not familiar with c-lightning, but I know that LND let’s you open two channels with the same peer. As you mentioned, dual-funding is possible but has not yet been implemented.


How to debug lightning-cli invoice I tried:

lightning-cli invoice 100 invoice20190126 payme

and nothing happens. How to debug?

I have copy and pasted the command to my c-lighting node and it works producing the following output:

lightning-cli invoice 100 invoice20190126 payme
{
  "payment_hash": "af2a2e0a6f4924f755e296c219ade5f2c65616fcec5bb8e62b253b8a71a442cb",
  "expires_at": 1548528927,
  "bolt11": "lnbc1n1pwye8cdpp54u4zuzn0fyj0w40zjmppnt097tr9v9hua3dm3e3ty5ac5udygt9sdqgwpshjmt9cqp2rzjqgj8m8dsm7h75az7lry7zc0txghh8tpl3pvdsuctdlvhy4r50nnkkzrgpvqqf0cqqqqqqq05qqqqraqqjq9c06msw62wushzceav74p2zzmznmtud4c3hkw6keqvquxnm6kaxry4rm7aerwppl4jn5xm7tyjxvvyyve5w06slwm7fvxfspx363j9cqcevtr7"
}

Which version of c-lightning are you using?
Also there was recently a change of the JSON RPC API due to the new plugin system. Could it be that you have not updated lightning-cli but only lightningd?


Flow when block is created I believe I know what is required to create block.

1.get previous hash(previous block is published)
2.collect transactions
3.proof of work(mining)
4.timestamped
5.audit by other nodes

Please tell me in what order these are done.

The order is 1, 2, 3, 5. There is no timestamping; the block itself provides timestamping via the proof of work.

Also, the step 3 is not 'mining', the whole process is what is called mining.


Is the purpose of proof-of-work the immutability of the blockchain? I have a disagreement with a person: I believe that the primary and most important goal of including proof-of-work (and therefore the nonce) in a block is to make it hard for an attacker to change that block (and since we are talking about a chain the next ones) without committing enough resources to recalculate not only the current but also all the blocks after that. Without it the attacker could simply create forks of the blockchain without any problems (free).

He claims that it is a mechanism is there to solve the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

Who is more right?

Immutable transactions are a consequence of blockchain-based systems when the following are true:

There is a cost (in currency and in acquiring materials) of producing a block consistent with the rules of the protocol, and this cost cannot be circumvented
The cost is great enough where incurring this cost to increase the length of the blockchain is more profitable than incurring this cost to fork the blockchain
As part of the rules of the protocol, past transactions cannot be altered by future additional data

Proof of work fits into this because it is provably costly. It requires energy, and it also requires development time and materials to create machines that use this energy efficiently. This cost prevents forks from being supported, as you have limited energy and you can only use that energy once.

This contrasts with Proof of Stake, or an IP based voting system because a lack of energy requirement means that there an incentive to support all forks. This is referred to as the Nothing-at-stake problem.


How can miners alter timestamps to prevent or delay BIP09 feature activation? In bitcoin mailing list , a proposal had the following concern.

  BIP 09 is vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically)

Can anyone elaborate on what and how is this fiddling carried out? Why does this raise the difficulty significantly?

Blocks have a field in the block header which is the time stamp. However this time stamp is set by the miner and can really be changed to whatever they want (although there is some restriction).

  Can anyone elaborate on what and how is this fiddling carried out?

BIP 9 has a start time and a timeout time which indicate the time period that a proposal can be signaled for. This times are based on the Median Time Past (MTP) which is the median time of the last 11 blocks as reported by their time stamps. Since miners can manipulate the time stamps, they can change the time stamps on their blocks so that the MTP is never past the signalling start time or so that the MTP is past the signalling timeout. This can delay signalling from starting and end signalling quicker.

  Why does this raise the difficulty significantly?

The difficulty is calculated by looking at the block time stamps. The difficulty is adjusted so that 2016 blocks happen over 2 weeks. The difficulty will rise if the last 2016 blocks were found in less than 2 weeks, and it will drop if they were found in more than 2 weeks. If miners were to increment their time stamps so that each block had a time stamp of 1 second after the last block, the difficulty retarget algorithm would think that 2016 blocks had been found in 2016 seconds so the difficulty would increase to compensate for this perceived fast blocks.


What were some discussed and current potential issues with pre-forked Bitcoin coins from August 2017 that have never moved since then? I was speaking to a friend that mentioned that there were issues with pre-forked Bitcoin coins from Aug 2017 that never moved. He wouldn't tell me exactly what the potential issue was, but what were some discussed or potential issues with these unmoved pre-fork UTXOs?
Is it a potential double spend that could happen on these coins that never moved?

No, there is no such problem. When BCH developers thought about introduction replay protection, they first agreed on the OP_RETURN-based one. Then they changed their minds and decided to use the better SIGHASH_FORKID-based one (see details about BCH replay protection).
Their first replay protection wasn't removed. It expired with block 530,000. After that block, unless you had moved your coins, it would have been impossible to separate your coins using that method.
That didn't matter to anyone then, since the second replay protection method introduced was made mandatory and worked perfectly. It was actually good enough to be exemplary (Bitcoin Gold copied it).

If you have pre-2017 coins, then you have BTC, BCH, BCHA, and BCHSV. To split those, send your bitcoins and BCHs to Coinex and they'll split it for you. (It is suggested to check that your transactions don't have nLockTime.)


What do I need to know about mining difficulty before starting a bitcoin mining startup? I am working towards starting a bitcoin mining startup in China. I can do the profitability from various calculators available online but I need to know about the difficulty level. The difficulty level has increased in the past, causing dedicated devices like antminer s1 to become obsolete. What should I know about difficulty?

If you want to extrapolate what the difficulty will be in the future, here is a chart you can look at:

http://bitcoindifficulty.com/

The big thing about difficulty is that it's hard to predict. In general, it's almost always increasing due to better hardware, but it's hard to predict how much it'll increase because bitcoin hardware increases with innovation, something that's intrinsically hard to predict.

Generally, there's a lot of guesswork involved and forecasting to do as a businessman.


How is segwit2x different from segwit? Today everybody got the news about the potential segwit2x adoption. However, I am trying to understand:
while both of them based on the same segwit principals how they are different? Is it about the blocksize, signaling or is it about the implementation?

SegWit2x is a combination of both SegWit and a 2MB hardfork (to activate three months after SegWit).

SegWit2x uses a different 'bit' for signaling (bit 4 instead of bit 1) than SegWit.

SegWit (BIP141) is not activated at the moment because it requires 95% of the mining hashrate, and not enough miners support SegWit at the moment, because some miners want a hardfork to increase the blocksize. To work around this the proposal of BIP148 allows users to force the miners to mine SegWit blocks by orphaning other blocks after August 1, 2017. BIP149 is a similar proposal, but will activate 11 months later. The vast majority of the core developers prefer BIP141 but most find BIP148 and BIP149 acceptable alternatives.

SegWit2x differs in implementation because of the activation of the 2MB hardfork and the lower activation threshold of 80% of the mining hashrate. SegWit (BIP141/BIP148/BIP149) itself has been developed by dozens of developers for over a year, has been tested extensively and has been ready for activation for some time now. It also has been successfully activated in Litecoin already. SegWit2x however is being developed at the time of writing by just a few non-core developers, although SegWit2x aims to be 'minimalistic', some people still consider this a risk because there is only a few months for development and only 2 weeks for testing.

At the time of writing the percentage of blocks signaling support for SegWit2x is at 78% of the mining hashrate:
https://blockchain.info/charts/nya-support


In rippled.cfg, what to use for [node_db] on Windows? I am trying to run rippled, but it is stating that I am missing [node_db] from rippled.cfg. In that file I can see

# Note that HyperLevelDB is unavailable on Windows platforms
#
[node_db]
type=HyperLevelDB
path=db/hyperldb

What should I put in for [node_db] on Windows?

At the time only SQLite is available on Windows platform, so the correct configuration is:

[node_db]
type=Sqlite
path=hashnode.db


Bitcoind functionality w/o running a full node I'd like to do some of the example in "Mastering Bitcoin, Programming the Open Blockchain" using bitoind on my Ubuntu system. Is there a program (possibly bitcoind itself) that allows me to do this w/o setting up a full not which I can currently not do for Hardware reasons?

I would mainly like to be able to explore transaction with comments such as bitcoin-cli decoderawtransaction for instance.

Many thanks and sorry if this is a stupid question.

I guess you could use some API that provides the same functionality.

See https://chainquery.com/bitcoin-api/decoderawtransaction

  bitcoin-cli decoderawtransaction

And much more calls/commands are listed there.

Does this fit your needs?


32k Transaction Size, 0.0005 Fees. Will it ever be confirmed? https://blockchain.info/tx/779afbdbdb03d13743626c8b1028404a6b16e65a2373ab5f744d206f34996c9a?show_adv=true

I made this TX from okcoin with 0.0005 (default) fees.
After 1 day it finally showed up in the blockchain, now after 48h i see no confirmation. The Transaction size seems really high, compared to the
average of 250-500 byte. Will it be confirmed eventually or will mempool reject it ?
I read that happens already after 72h ?
Should I double-spent to cancel it ?

Also, why is it so large ? Could it have been avoided using a new RX address.

Thanks a lot in advance !

If you take a rule to spend 20 satoshi per byte you should spend 651380 Satoshi which is 4 times more than you provided in the transaction. It could be likely that you won't get confirmed by a miner, you could make a new transaction and put it through of course.

Both won't go through that's for sure.


Full node vs lightning node What is the difference between a full node and a lightning (network) node?

If a lightning node, that is not a full node, opens a payment channel with another lightning node, how can the first peer check that the other peer does not send a "malicious" closing-channel transaction to the blockhain?

A 'full node' refers to a fully validating node on the bitcoin network, meaning the node validates each block and transaction that happens on the network. An example of this is bitcoin-core.

A 'lightning node' refers to a node on the lightning network, which is a network that exists on top of the bitcoin network. The lightning network has it's own protocol for communicating lightning transactions, and the lightning node will follow that protocol in order to interact with the network. An example of this is lnd.

  If a lightning node, that is not a full node, opens a payment channel with another lightning node, how can the first peer check that the other peer does not send a "malicious" closing-channel transaction to the blockhain?

A lightning node will interact with a bitcoin full node in order to watch the chain for such transactions. Since the lightning network operates on top of the bitcoin network, the lightning node will need information from the bitcoin network in order to function properly.


How can I create a new wallet on Bitcoin Core? How can I create a new wallet on Bitcoin Core (Bitcoin QT)? I forgot my old password, so I can't create transactions using the old wallet. I don't have money on my old wallet, I just need to create new wallet without the forgotten password.

Bitcoin Core will create a new wallet if it cannot find the wallet.dat in the Bitcoin Core folder.

Close Bitcoin Core.
If the wallet still has a balance, or addresses from the wallet were given out, back the old wallet.dat up: Move it to a different directory or rename it. If you are sure that it was never used, you may delete it instead.
Restart Bitcoin Core. A new wallet will be created.

If you don't know where to find the wallet.dat, check here: Where is the data folder for bitcoin-qt?


Do wallets save a backup of my private keys and seed? Let's say that I do not trust a lot in myself and my ability to not screw my computer, so also my private keys.

Knowing the concept of wallet HD and having seeds to recover all your private keys linked to the seed, how does this work, from wallets perspective?:

Does a wallet provider save my private keys (in a secure way) in order to restore them in the future with my seed, if I require it? (Providing paraphrase or information required)
Depends on the wallet provider whether they save a encrypted copy of my private keys to restore them in the future (just in case I remove or lose my local wallet file) or others that they do not save any private data, leaning the entire private keys in my local machine ?

This question is related with some FaQ from.some wallet providers, which they offer the option to restore your private keys providing the seed. This looks like they have a copy of your private keys, otherwise whether you are the only one that have them  and you lose your private keys, there is no way to restore it.

It depends on what wallet you are using.

Most people prefer to use wallets that do not have knowledge of your private key outside of your machine, such as hardware wallets, electrum, Bitcoin Core. This is for safety, since any provider who has your keys could easily decide to move all your coins to an address that only they control, and rob you blind.

That said, there are some services that offer custodial services, usually in conjunction with exchange services. In fact, every exchange is a custodian keyhold for the deposit addresses they assign you on their platform.

A few years ago, perhaps there was some merit in trusting a reputable custodial service who had the infrastructure to always backup keys. In 2018, BIP32/39/44 can make a backup as simple as writing down a handful of words and keeping it very safely, so maintaining control of your keys is the preferred option.


Why are people creating so many coins and can all of them sustain? I wonder why people are creating so many crypto currencies and how many of them may sustain? Can anyone here predict what is going to happen? (Not asking to predict what coins are going to sustain as no one would know answer to that).

Many other crypto currencies are inspired by bitcoin, but have a goal that differentiates them from bitcoin. For example, litecoin was design to combat the development of ASICs, so that people with regular computer hardware can mine them. Namecoins provide secure key-value pair storage, and devcoins are somehow used to fund open source endeavors. Others just want to piggy back on the success of bitcoin.

The success and sustainability of these other currencies (often called altcoins) depends on whether or not you can convince others that they are valuable. For example, Namecoins are gaining popularity because you can buy .bit domain names with them.

Many altcoins will likely remain worthless forever, but people will assign a value to some, and those may be sustainable.


Is there any way to mathematically optimise Bitcoin transfer fee? Say you want to transfer X amount of Bitcoins between wallets and Y amount of transaction fee will be levied. Now you have option to send extra Bitcoins for the same amount of transaction fee, so how can you calculate what is the maximum amount of Bitcoins that can be transferred for that Y amount of transaction fee?

The network fee doesn't depend on the amount of BTC that you're sending, it depends on the total size of the transaction. So there is no such thing as "maximum amount of BTC that can be transferred". You transfer as many BTC as you want and you determine the fee per byte. The miners will include your transaction on a block depending on that fee.

To calculate an optimal fee I recommend you have to take a look at the mempool taking into account that the transactions with greater fee will be processed first. In general, except that you're on a hurry or the mempool is overloaded, a fee of 5 satoshis/byte would be enough.

For further details take a look into How is transaction fee calculated?


difference between inbound and outbound connection I'm running a bitcoin full node (bitcoin core) via Tor.
I noticed I have only outbound connections (using maxconnections=16 in the conf file), but not even an inbound one.
So which is exactly  the difference between inbound and outbound?
I'm able to regularly receive update tips and relay my transactions to the network however.
Furthermore, I set the onlynet=onion option, so I should exclusively receive from and relay to onion addresses

When your client start the connection with another peer it is outbound, otherwise it is inbound.

If you want to be sure that your tor node is properly setup and that other peer can connect to you, check: https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service


Multiple input address to a single output address in one transaction? If I have Wallet A with one address (call it A1) and Wallet B with 2 addresses (B1, B2), can I send BTC from A1 AND B1 to B2 in a single transaction thus incurring a network fee only once?

can I send BTC from A1 AND B1 to B2 in a single transaction thus
  incurring a network fee only once?

Absolutely. A transaction may contain multiple inputs and multiple outputs. The trick will be to get the wallet to do this for you. It will need to be aware of both address's private keys, and be able to let you select which inputs to use. Alternatively, you could construct the transaction manually.

See http://en.bitcoin.it/wiki/transaction


Where is the code making OP_RETURN a standard transaction type? I am looking through the bitcoin github history. I am trying to find the commit where OP_RETURN became accepted as a standard tx. This was included in the changelog for Bitcoin Core 0.90. Any help would be appreciated.

I'm looking through the Script Solver and see where OP_RETURN is included as a type in the template, but don't see where it returns true for any null data case.

Thanks.

This is the PR that made OP_RETURN outputs standard:

  https://github.com/bitcoin/bitcoin/pull/2738

The commit:

  https://github.com/jgarzik/bitcoin/commit/a79342479f577013f2fd2573fb32585d6f4981b3

The current code:

  https://github.com/bitcoin/bitcoin/blob/v0.11.0/src/script/standard.cpp#L56-L58

    if (GetBoolArg("-datacarrier", true))
        mTemplates.insert(make_pair(TX_NULL_DATA, CScript() << OP_RETURN << OP_SMALLDATA));
    mTemplates.insert(make_pair(TX_NULL_DATA, CScript() << OP_RETURN));


How can I limit bandwidth usage in Bitcoin-qt client? I've just finished the intial blockchain download/verify in my BitcoinQt client (17 hours..) and I now see that BitcoinQt is happily eating all of my upstream bandwidth. (About 110kByte/sec on my ADSL line.)

I'm going to be applying bandwidth limits to the app using Waterroof, which should probably work --

But shouldn't there be a built-in method for BitcoinQt to be more polite about its bandwidth consumption?

If your goal is just to get a stable Bitcoin node running, and not to contribute to the network, you can add listen=0 to your bitcoin.conf file. This generally (though not always) keeps your upload bandwidth in check.

If you want to contribute to the Bitcoin network without using up too much of your own bandwidth, however, there are ways of limiting your upload speed for Bitcoin Core (Bitcoin-qt) only. Instructions depend on your OS, so what follows is a breakdown on what to do with each OS.

IMPORTANT NOTE: If you limit the bandwidth of Bitcoin Core far below your actual upload speed, it can actually harm the Bitcoin network instead of helping it. To be a responsible maintainer of the Bitcoin network, you should test your upload speed and then set your outgoing bandwidth limit to be as close to your actual speed as possible (e.g. 90%). This guide is intended solely for people whose internet connections go unresponsive due to Bitcoin Core completely saturating their upload bandwidth.

The following instructions are abridged from this article I wrote recently:
https://www.maxlaumeister.com/blog/how-to-limit-bandwidth-of-bitcoin-core-on-windows-mac-os-and-linux/

Limiting Bitcoin Bandwidth on Windows

Download and Install NetBalancer.
Start Bitcoin Core if it isn’t already running.
Run NetBalancer.
Find “bitcoin-qt.exe” in the list of running applications in the NetBalancer dialog and double-click it to change its bandwidth rules.
Under “Upload Priority” choose “Limited”, set the maximum amount of bandwidth for Bitcoin Core to use, and confirm.

You’re done! NetBalancer will now sit in the background and make sure Bitcoin Core doesn’t use more bandwidth than you want it to.

Limiting Bandwidth on Mac OS X

OS X 10.10 Yosemite and later

For OS X 10.10 Yosemite and later, there is no easy way to limit the bandwidth of a particular application, but the overall system bandwidth can be limited as follows:

Visit Apple Developer Downloads and log in with your Apple ID.
Search for “Hardware IO Tools for Xcode” and download the latest stable (non-beta) version.
Open the .dmg and double-click “Network Link Conditioner.prefpane” to install the prefpane. From now on, you can enable/disable Network Link Conditioner from System Preferences.
From the Network Link Conditioner pane in System Preferences, click “Manage Profiles”, then click the “+” button to add a new profile.
Edit the profile and add your desired maximum upload speed.
Save your edit, exit the profile manager, choose your new profile, and flip the big switch to enable the limiter.

Mac OS will place an icon in your notification tray so you remember that it’s on. Unlike the Windows/Linux solutions, this will limit the bandwidth for your entire system, so be sure to turn it off you’re not running Bitcoin Core.

OS X 10.9 Mavericks and earlier

For OS X 10.9 Mavericks you can use IceFloor to configure bandwidth rules. For 10.8 Mountain Lion and earlier, use Waterroof. Alternatively, if you want a simple way to control the overall system bandwidth limit instead of just Bitcoin Core, follow the instructions above for OS X 10.10 Yosemite and later.

Limiting Bandwidth on Linux

Make sure you have tc installed by typing tc at the command line. If you get “command not found”, install tc using your favorite package manager. If you're on a Debian-based distribution, the easiest way to install tc is by using apt-get:

sudo apt-get update

sudo apt-get install iproute2
Download the tc.sh script from the official Bitcoin Core repository using wget:

wget https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/qos/tc.sh
Open the script in a text editor. Find the line that says IF="eth0" and change eth0 to reflect the network interface that your internet connection runs through. To get a list of your computer's network interfaces, use ifconfig on the command line. My computer is connected wirelessly through wlan1, so the IF line of my tc.sh looks like this:

IF="wlan1"
LINKCEIL should reflect the limit of the network interface, and most likely does not need to be changed.

LINKCEIL="1gbit"
Change LIMIT to be the maximum bandwidth you want Bitcoin Core to use (I chose 1mbit). If you don’t have any other Bitcoin Core nodes in your local network, you can delete the line that says LOCALNET. This line is there to make a bandwidth exception for port 8333 communications within your local network (i.e. not out to the internet).

LIMIT="1mbit"

Leave the rest of the commands in tc.sh alone unless you know what you're doing. The final top section of my tc.sh ended up looking like this:

#network interface on which to limit traffic
IF="wlan1"

#limit of the network interface in question
LINKCEIL="1gbit"

#limit outbound Bitcoin protocol traffic to this rate
LIMIT="1mbit"

Exit your editor and make the script executable with the following command:

chmod +x ./tc.sh
Run the script as superuser:

sudo ./tc.sh

Your Bitcoin Core bandwidth will be throttled until you reboot your computer!

Optionally, you can set the script to run every time you start your computer. Instructions for running scripts on boot will vary depending on your Linux distribution. On Ubuntu, one of the ways to run a script on boot is by adding the script to your /etc/rc.local file.

Conclusion

Hopefully this post was helpful in showing you how to limit the bandwidth of Bitcoin Core! For the full version, including images and extra information, check out the original article here.


Do PCI USB risers lower the hashing rate? I have a PCI USB riser like this one:

I have 2 identical video cards with one plugged directly into the motherboard and one plugged in via the PCI riser.  I am seeing a hash rate of 290 KH/s on the one directly connected to the motherboard and 210 KH/s on the one connected via the riser.  The riser is connected to the PSU so it is powered.  There is no need to short the PCI slot.  I have tried this riser in both a PCI x1 slot and PCI x16 slot with the same results.  The video cards are both GTX 580.

Could the added latency of going through a USB wire account for this decrease in hash rate?

Using another video card (GTX 750 Ti FTW), I was able to confirm a decrease of about 100 KH/s while connected to the PCI USB riser.  I have tried 2 separate risers with 2 separate video cards and every time a PCI USB riser is involved, my hash rate is lower than when connected directly to the motherboard. The motherboard is a Gigabyte GA-X58A-UD3R. The BIOS has been updated and I only see BIOS options to change the PCI Express Frequency and PCI Express Clock Drive.

I am having a hard time finding an answer online and I need experts, please help.  If these USB risers decrease the hashing power then I'm not sure why people want them.  I want them for the added distance I need between my motherboard and GPUS in my setup but perhaps I should alter my setup to allow for the ribbon cable riser version.  I appreciate your recommendations.  Could there be a setting that accounts for this latency and keeps an optimal hashing power?

The general consensus is like Robert said: there SHOULDN'T be any difference, but there is!

Having the same problem here!

I'm running Windows 8.1 Pro (64-bit) with five (5) of the new GeForce 750 Ti cards by EVGA (FTW model).

They hash at 320 KH/s when connected to the PCIe 16x slot, but get capped/maxed at 295 KH/s when connected using 1x to 16x riser cables.

All riser cable molex plugs are connected to power supply.
All cards have their PCIe 6-pin power plugs connected as well.
Updated BIOS of cards to take up 65 watts max (or even up to 100 W) to no avail.

Power supply: 1000 watts (more than enough)

Motherboard: BIOSTAR H81S2 (made for mining) ver. 6 - latest BIOS

UPDATE: I thought the culprit was the motherboard, so I bought the ASRock H81 Pro BTC (made for mining) motherboard.  SAME EXACT STORY!

I was about to try a USB riser cable instead, but I see that the OP (Scott) has the same issue with those as well.

Now I'm leaning towards a driver or OS issue, but I'm quite certain it's because of using the 1x slots, though, AMD cards are hashing at much faster rates!  So that's interesting.  What's going on here?!

I will try running on Linux.

I contacted BIO-STAR for tech support and they'll get back to me.  Their R&D department is looking into this.

I already tried setting the PCI speeds for the slots, in the BIOS, to Gen2, manually (instead of Auto), and that didn't help.  (Because I found someone on the internet with a similar issue and they said this fixed it for them, but it's not exactly this issue they've had).

In the BIOS I tried changing PCI Latency Timer up to 248 PCI Bus Clocks - didn't help!

In the BIOS I tried changing the Maximum Payload & Maximum Read Request to 4096 bytes - didn't help!

I've disabled redundant services and components in Windows - didn't help!

I ran the DPC Latency Checker tool and things seem stable so that's not the issue either.

Interesting to note:

While overclocking above a certain MHz for the core or memory, through the 1x riser, once the hash rate reaches 295 KH/s, it does not go any higher no matter how much you overclock, however, the overclocking utility of choice (EVGA Precision X, ASUS GPU Tweak, MSI Afterburner) will confirm the higher clock rates running on the cards.  If connected through the full PCIe 16x slot, this 295 KH/s limit is non-existent, and the more you overclock past that same amount of MHz as before, the higher the hash rate.

Doesn't matter which version of CUDAminer is being used.

UPDATE: Looks like it's a CUDAminer issue:

http://www.overclock.net/t/1468166/gtx-750-ti-mining/190#post_21890197

  Cudaminer apparently has a high PCIe bandwidth utilization...thus when
  going from x16 mode to anything lower, as you get closer to x1 mode
  (risers or not), you're going to see degradation of performance (10-30
  kH/s for 750 Ti in my experience). Cudaminer author is apparently
  going to be working to fix this ASAP since he'll soon be operating a
  750 Ti rig with riser assemblies.


Is mining faster with 2 GPUs in crossfire or with 2 PCs with one GPU each? Is it faster to have 2 separate computers with the same graphics card but different specs, or one computer with 2 GPUs in crossfire?

By math, they should perform the same im guessing at the same clock speeds

They do indeed perform exactly the same

Crossfire is not encouraged as it gives no advantage and may impact your overall performance. The computation is done in parallel on each card so there is no need for them to communicate among each other.


External GPU for mining Of course, there are lots of ASICs out there with exponentially more hashing power. But I'm not yet ready to invest and dedicate to one coin. Is there a mining solution in which one can set up an external GPU enclosure and use those to mine? If so, how would one go about setting it up? Thanks!

You would likely spend as much buying a couple of decent GPUs as you would buying a small mining rig for sha256/scrypt (i.e. Bitcoin/Litecoin).

You can use "riser cables" to connect a PCI-E GPU to your computer's motherboard without it being inside the case but there is a limit on how long these can be (safety / fire risk).. I think 12-15" is about as long as they get realistically.

FYI:  GPU mining doesn't need a powerful computer, any old computer will do so long as it has suitable PCI-E ports and a few Gb of RAM.


How to get all cryptocurrencies real-time statistics with no limit and free? How can we get almost all real-time information of cryptocurrencies (rates, transactions, live prices, blocks info, wallets, etc) for developing new cryptocurrency statistics and exchange reference (like Binance)?

We can use blockchain.com's API for BTC and LTC and some other references like chain.so, block.io etc, but what we need to get all stats for all cryptocurrencies?

I mean how Binance getting this bunch of information? and where can we get them too?

I know there is some website that sell these information and their own APIs but how they got these? and actually how can we get this bunch of information freely?

https://blockchair.com/ is pretty good for data analysis on 9 different blockchain it allow you to filter by lots of settings like date, reward, hash, output etc... You can also directly download the data they offer in different format.

And they also have an API: https://github.com/Blockchair/Blockchair.Support/blob/master/API_DOCUMENTATION_EN.md


Get private-keys from bitcoinj I'm using bitcoinj library for bitcoin.

I want all private keys of all my generated addresses.

How can I achieve that? Please help who knows this answer.

Thanks.

I have write this sample code, hope this helps

public class Main {
    private static NetworkParameters params = NetworkParameters.testNet3();
    public static void main(String...args) {
        String mnemonic = "brisk wood symptom party betray ozone dad super beyond sea memory power pig business extra";
        DeterministicSeed seed = null;
        try {
            seed = new DeterministicSeed(mnemonic, null, "", new Date().getTime());
        } catch (UnreadableWalletException e) {
            e.printStackTrace();
        }
        Wallet wallet = Wallet.fromSeed(params, seed);
        System.out.println(wallet);
        DeterministicKeyChain keyChain = DeterministicKeyChain.builder().seed(seed).build();

        // Derive 100 children, default lookahead is 100
        keyChain.maybeLookAhead();

        // Get M/0H/0/5 key, drive address along with other info for specific path
        DeterministicKey key5 = keyChain.getKeyByPath(ImmutableList.of(ChildNumber.ZERO_HARDENED, ChildNumber.ZERO, new ChildNumber(5)), false);

        System.out.println(key5.toAddress(params).toString());

        // derive 100 addresses along with private key
        System.out.println("_________________________");
        int i = 0;
        while (i < 100) {
            System.out.println(wallet.freshReceiveKey().getPrivateKeyAsHex());
            System.out.println(wallet.freshReceiveAddress());
            i++;
        }

    }
}


Unable to send 'version' message correctly Few days ago I've found this article about using raw Bitcoin protocol and now I'm trying to make my own transaction with Python. But I'm already stuck on sending version message.

I've tried to use code snippets from the article. According to it, this code below should work, but Wireshark can't recognize anything and there's no verack response

import msgUtils
import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("NODE_IP_ADDRESS", 8333)) # Shodan search 'port:8333'

sock.send(msgUtils.getVersionMsg())
sock.recv(1000) # receive version
sock.recv(1000) # receive verack

Maybe it don't work because article was written in 2014 and now it's totally outdated?

The msgUtils.py code didn't work with 64-bit Python due to a bug. I've fixed it, so you can try the updated code. (I'm the author of the article.)


Retrieve all Unspend Output given a priv key Is it possible to retrieve all Unspend Output transaction given the private key?
I have noticed that different wallet give me different balance for the same Private Key. For instance, Atom and BitPay give the same result but they use BIP44. Exodus and Defi Wallet give the same result and they use BIP84. On these wallets I have given the same Private Key but every wallet sees part of the Unspend Output. Hence my question.
Thanks
https://bip39.org/

generally speaking the answer is no: you should generate every public address to check it's balance and the possible addresses are too many to be checked all.
in your case, if you remember the wallets where you imported the keys, you can only check the derivation paths used by them.
even the addresses that can be generated from the first branch of the derivation path are too many to check them all, the wallets usually stop generating public keys to be checked when they find a certain number (which varies depending on the wallet, usually a few thousand) of unused addresses in a row.
so in case you have large blocks of unused addresses among the addresses used, you can't even trust the automatic wallet balance check for it's specific derivation path, but you should generate other addresses on your own to verify their balance.
this is a very rare case that hardly occurs in real life, but it is good to know anyway.


Is there already an existing closed cash flow loop for the currency BTC? Loop means:

merchant will get delivered goods from producer in BTC
customer will buy goods from merchant in BTC
factory worker will get salary as BTC (at least in parts)

At this loop there is no necessity to exchange BTC to local currencies and vice versa.

Is there any producer at any country known that can pay salaries legal in BTC?

If not, how can we achieve this closed loop?

Closed vs open loop isn't a black or white definition.  For example even in the US were you have significant velocity of money companies buy parts in other currencies (from other countries), consumers imports goods manufactured overseas, and investors buy foreign stocks.

So there is no such thing as a completely closed loop.  I think what you are asking is what can be done to keep transactions in BTC either perpetually or for longer (before being cashed into fiat).  Unfortunately that is a slow process.  There is no grand over arching plan rather each individual seller increases the potential to the currency to be recirculated more before being exchanged.

I see three major factors determine how likely acquirers of BTC will keep the BTC over selling for fiat currencies:
1) Availability of goods.  The more goods and services available in BTC the more valuable the currency is relative to fiat currencies and the more likely someone who acquires BTC will keep them.

2) Value of goods.  If goods are sold in BTC at a discount that will increase the value of BTC.  If good are sold in BTC at a premium that discounts the value of BTC.

3) Price stability.  The more volatile the price the more risk of losing purchasing power by holding BTC.  That will reduce the likelihood that an acquirer of BTC keeps those BTC over more stable currencies.

There are no easy answers to the problem of increasing the length of BTC loop as BTC isn't a planned economy.  As an individual the best thing you can do is to offer goods or services in BTC and look for merchants who do the same.


Are Hashed Timelock Contracts and Zero-Knowledge Contingent Payments the same thing? This answer to How is a node in the middle prohibited from keeping the money in a routed Payment in Lightning network? describes how a Hashed Timelock Contract would be used to exchange the "secret" for a payment. This sounds a lot like the Zero-Knowledge Contingent Payment described by Greg Maxwell.

Would I be correct in assuming that the HTLC would be implemented including a ZKCP?

Not really. Both use OP_CLTV, in order to recover from a situation where one side refuses to participate in the protocol, but other than that, they're pretty different.

ZKCP has a zero knowledge proof communicated outside of the blockchain. On the other hand, HTLC passes signed transactions back and forth to update a channel.


How was bitcointalk attacked in Dec 2013? There was a man-in-the-middle attack on bitcointalk on Dec 2013.

  News: If you used your password to login between 06:00 Dec 1 UTC and
  20:00 UTC, then your password may have been captured in a
  man-in-the-middle attack, and you should change your password here and
  wherever else you used it. If you were only logged in via the
  "remember me" feature, then you're OK.

How was this executed? Didn't bitcointalk use SSL? Are there technical details on the attack vector?

The general description has been given before me.Here are technical details on the attack vector.

Assuming the following:

The attacker got a certificate that the client will accept, via poor cert validation or other means.
The attacker knows the IP address of the server, and is in a position on the network to do things like ARP spoofing.

Ettercap includes modules for ARP, DNS and DHCP "interventions", and supports direct SSL MITM