What was the original rationale for limiting the maximum push size? The current Bitcoin client filters out any pushes beyond a certain size.

static const unsigned int MAX_SCRIPT_ELEMENT_SIZE = 520; // bytes
[...]
if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);

What's the point of doing this? Does it prevent an attack?

How difficult would it be to change this? Would increasing this constant require a soft/hard fork?

This limit is long standing and unexplained, but it didn't always have that particular name. It was dubbed MAX_SCRIPT_ELEMENT_SIZE in this commit, where previously it was just a magic number in script.cpp. The restriction is found throughout the entire history from master until 0.3.22, but is missing from the 0.1.3 source. You could speculate that it was intended to be an anti-DoS restriction, but these releases retained OP_CAT which would have allowed for nearly infinite sized stack elements regardless of the sizes of data pushes.

The 520 byte push size severely stunts Pay to Script Hash, as the entire script is pushed onto the stack it must respect the push limit. For a P2SH multisignature script this sets the upper limit to n-of-15, any larger and it would be unspendable due to 520 byte consensus rule.

Increasing this limit would be a hard forking change.


OP_EQUAL not working properly I went to https://siminchen.github.io/bitcoinIDE/build/editor.html to try some bitcoin scripting and I wrote this script:

<1PUzZ61FSVTn12CafJC85Vy1ts3BoFcXdU> OP_HASH160 <E105E01B92119CC55D753248CE3A32C82A9BB308> OP_EQUAL

Screenshot:

My script fails even though both the hashes are same. Why?

Because they aren't the same. It appears that this script IDE interprets things inside of angle brackets (< and >) as strings, not as hex values. However a hash is not a string, it is a sequence of bytes which may be represented using hexadecimal values.

So what your script is actually doing is putting the string 1PUzZ61FSVTn12CafJC85Vy1ts3BoFcXdU on the stack and then hashing it and putting the byte value E105E01B92119CC55D753248CE3A32C82A9BB308. But then you push the string E105E01B92119CC55D753248CE3A32C82A9BB308 onto the stack except this has a byte value of 45313035453031423932313139434335354437353332343843453341333243383241394242333038. The OP_EQUAL is then comparing the two byte values E105E01B92119CC55D753248CE3A32C82A9BB308 and 45313035453031423932313139434335354437353332343843453341333243383241394242333038 which are obviously not equal to each other and thus the script fails.

Instead you need to tell this program that you want to push the byte values E105E01B92119CC55D753248CE3A32C82A9BB308 to the stack, not the string representation of these hex characters. To do that, just don't surround it with angle brackets. This works for me:

<1PUzZ61FSVTn12CafJC85Vy1ts3BoFcXdU> OP_HASH160 E105E01B92119CC55D753248CE3A32C82A9BB308 OP_EQUAL


Does BTCE API have a fast ticker? I think the title is pretty self explanatory. I know that MtGox has a fast ticker, so I was just wondering if BTCE had a similar function.
Thanks,
Paul

If you mean a ticker that is constantly up to date then yes. See here .
 As far as a way for pulling that data here is a php example: https://stackoverflow.com/questions/21021266/parsing-json-data-from-a-remote-server


Is four confirmations enough if the network hash rate is so high? The point of waiting for six confirmations is that it becomes near impossible to create six blocks vs the network. So double spends a effectively eliminated.  With the hash rate of the network so high, is four blocks enough to have the same security?

Also, what about in the case of a fork like the one that resulted in 23 blocks?

Technically, one block is enough. However, a single block orphan occurs with sufficient frequency that many Bitcoin business prefer three or six confirmations. The difference is more a matter of personal choice.

The hash rate of the network does not significantly impact the time between blocks because of the difficulty level. The difficulty level helps maintain the block timing at approximately every 10 minutes.

The 11/12 March 2013 blockchain fork was a bit of a special case. Only one known double spend occurred, and that was a result of someone who crafted a raw transaction involving a company (OKpay) that did not heed the warning to cease transacting until the fork was resolved.


New to Bitcoin - Need help understanding the mining part I had a quick read of the basics of Bitcoin and the mining, but i still don't understand why this is done. can someone please explain in simple terms...

The biggest problem with developing a peer-to-peer payment system with no central authorities is preventing a double spend.

Say you're developing a payment system to allow people to pay each other widgets. If Alice has 10 widgets, she has to be able to pay 10 widgets to Bob. And she has to be able to pay 10 widgets to Charlie. But if she can do both with the same 10 widgets, the system is broken. So, somehow, Alice paying 10 widgets to Bob must stop her from paying those same 10 widgets to Charlie.

Bitcoin solves this problem with a mechanism called "proof of work". It's a bit complicated to explain, but the key point is that it requires an enormous amount of computational effort to be placed on either of the two payments. The one that has this computational effort is the one that "wins". The cost to put the computational effort behind both transactions would exceed the value of the transactions and you'd never catch up anyway because the winning transaction would be getting more and more proof of work (called "confirmations").

Because this computational effort costs money, Bitcoin needs some way to reward those who do it. They won't just do it out of the goodness of their hearts. Eventually, transaction fees will probably do this, but in the early days, there were too few transactions and Bitcoins weren't valuable enough for transaction fees to pay for the proof of work needed to secure the system.

The genius of Bitcoins is that the designer(s) solved two problems with mining. They added a "block reward" that goes to the miners to reimburse them for their computational effort. This not only solved the problem of how you pay for the computations effort needed to secure the currency before transaction fees can do it but it also provided an automated and predictable way to create the currency in the first place.


How do cryptocurrency exchanges work with so many currencies at the same time? To implement automated deposits/withdrawals of a single currency for a business there has to be a lot of code in place specific for that currency. For example if I want to automate sending and receiving bitcoin - I would write an application around bitcoin’s software - bitcoin core. Obviously, there won’t be similar node software for every coin, say Ethereum, would have a different core, if it even has one (it’s an example). Would you need to write a new app that would adapt for that core? Then does it mean that big exchanges write new software that does the same job but for each coin? Where did I go wrong here, or is cryptocurrency development really this complex?

One way is to write software for each cryptocurrency as you suggest.
A lot of it would be reusable code as you can just interface via RPC with your wallets.
Another way is to use a wallet that supports multi currencies and then interface with that wallet.

But lets examine what really is required
depostis

those are essentially free as all you need is an address that you control. You can either create a list of addresses in advance and then use those whenever a user requests, or you can write code that creates these addresses. Now a lot of cryptos use the same elliptic curve therefore private keys can be reused across cryptocurrencies and you just create the appropriate addresses. Now of course you dont want your private keys online, so again pre-creating lists of deposit addresses makes sense

withdrawals

here all you have to do is be able to compose a valid transaction, sign it and put it on the appropriate network. This work will be the same for a lot of cryptos.

In the end i believe that exchanges do run wallets for each crypto they deal with, it helps with staying up to date with the chain, to spot re-orgs, and of course to interface with that particular cryptocurrency

This is just conjecture of course, i have never built a crypto exchange myself :)


Security within a deleting blockchain model Assume a blockchain model that contained no transaction data - just pure data. After a set time this data would simply be deleted, and entire blocks would be removed. How would the security model of the blockchain suffer? Would it make it easier for a "long chain" attack, and if so how can this be prevented?

The idea is to store data into the blockchain. Anyone could store data in this chain, and all nodes have a copy of this chain. There is a block race, to secure the blockchain as normal, but there would be no rewards since this is not a money based system. How the deletion is done is yet to be explored, but basically all nodes would agree all blocks older than x months be deleted from their systems.

Would an attacker be able to compute a longer chain if they know of the point at which data is deleted, then show this to the network and then make the network believe this is the correct and valid chain? If so, how can we stop this? (Assume the attacker has less than 51% computing power.) I have looked into timestamps, and time capsule based encryption, but what I want is a mechanism where an attacker cannot successfully create a block without some information that would only be revealed on a specific day.

Your system is pretty easy to implement. The major reason why Bitcoin nodes don't delete old blocks is that old transactions are needed to tell if new blocks are valid. But if the validity of new blocks doesn't depend on old blocks, than the contents of those blocks can be deleted without consequences.
You mention the problem of having a node on the network pretend that an old block is new. Bitcoin solves this problem in three ways:
Separate block header and block contents; keep block header forever
Bitcoin block headers are 80 bytes. They look like this:
<4 byte version> <32 byte hash of previous block header>
<32 byte hash of the block contents>  <4 byte timestamp>
<4 byte difficulty> <4 byte nonce>

That's small enough to avoid having to delete the block headers, ever, but enough to include a merkle root of what's in the block. You can delete the block, but keep the block header around. The difficulty field is necessary because Bitcoin difficulty can vary. The 4 byte nonce is added to make mining easier.
Record timestamp in block header
The timestamp is recorded in the block header, and the Bitcoin client rejects any block headers that are too far into the future or the past.
Record previous block in block header
Bitcoin includes the hash of the previous block header in the block header, which means that you can't take a previous set of block headers and pretend that they're new.
For example, if you've got these block headers:
A>B>C>D>E

You can't take C and append it to E, because other nodes will notice the mismatch between E and C's parent, B.


Are BIP 100, 101 and 102 being voted on now by Bitcoin miners? Are the BIP 100, BIP 101 and BIP 102 proposals being voted on now by miners? What is the procedure for a bitcoin miner to vote for a particular BIP and where can a tally of votes be viewed?

There isn't any blockchain voting for accepting a BIP: See How is a BIP accepted? and BIP0001.

Rather, the BIP is accepted or rejected on the basis of consensus. Consensus is never defined, but even if you interpret it fairly broadly, I don't think any of the three will reach consensus.

There are frequently blockchain votes about activating the new rules, but that's less of a mechanism to measure acceptance and more of a way to only deploy the new changes once enough of the network runs them that the switchover won't be disruptive.

There is a related issue, which is Bitcoin-XT, which grew out of several developer's frustrations with the process. That proposes to alter the blocksize according to BIP 101 once more than 75% of the blocks are created by Bitcoin-XT nodes. But that's not something within the BIP process.


What is the difference between BFT and PBFT What are the differences between BFT and PBFT?

I want to know the difference between these two concepts.

If there is any improvement in the BFT's limitations, let me know.

Please answer. Thank you.

BFT is a class of problems where a group of nodes needs to find consensus, where some of the nodes may be malicious. PBFT is an algorithm that generates consensus in one of those environments (specifically with signed messages and partially sychronous network). An good writeup is here: https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95


Can I see transactions in bitcoin-qt without downloading blocks? if I have a server with blocks on the local network? I have server with bitcoind (synchronized), port 18443 opened. And I tried to connect to rpc server with bitcoin-qt in my mac. With this configuration:
regtest=1
rpcuser=<login>
rpcpassword=<pass>
rpc_connect=<ip to server>

But bitcoin-qt writes that it is synchronizing, and to use the application you have to wait.
Can I use bitcoin-qt without synchronization?
P.S. Sorry for my english

It doesn’t work because the software doesn’t support operating like that. You can not connect bitcoin-qt to a remote RPC server.


Who issues the transaction of reward when a miner solves the block? I know that when I send money I create a transaction.  The transaction is unconfirmed, and then gets confirmed and the address owner gets the money in his wallet by summing up all the transaction of his public key address.

But what about the miner?

Suppose I am a miner with address x213123abcah23 and I solve a block and propagate it.  Who issues the mining reward to me?
Does Mr. Satoshi with his address send money to me or what?

The miner itself includes a special transaction in the block called generation transaction. Every block only has a single generation transaction.

This generation transaction transfers the block subsidy plus the fees of the block to an address controlled by the miner.

For intance, if you look at block 434868, there is a single generation transaction that transfers 12.96 to address 17ggdTQzKFwrKP1zgqb5Kjuw6CpGKaE6Jrw.


Promise-to-pay functionality without escrow where sellers vote if they should pay Is there a promise-to-pay functionality with no escrow where a seller can set a bitcoin address for buyers to send promise-to-pay bitcoins. Once seller fulfills his promise, the buyers will confirm theirs: if 50% or more of the buyers confirm their promise, seller gets the money.

Example: An author promises to write a book if readers pay him N bitcoins.
Once author's account has N or more promise-to-pay bitcoins author publishes book.
Once 50% (this percentage can be adjusted) or more payees confirm the money goes to the author.

That is referred to as M of N transactions.  So you have 6 buyers, and at least three must agree to the transaction for the funds to be delivered to the seller.

It's coming.

Why are m-of-n transactions not used today?


How many FPGA can be attached to one computer? I am looking at this. Dual FPGA X6500 Mining Card Rev 3 (Without Heatsinks)

So we connect the card via USB and the card will mine?

Should I buy one FPGA or several ones? Where do I attach the FPGA? PCI? USB?

From what I know, you can connect basically any amount of FPGA cards to one computer through USB hubs. Case in point:


did Satoshi anticipate large pools? Is there any statement about the design of Bitcoin alluding to dealing with large pools controlling a good part of the network? while it is true that pools can compete and people can "vote" by switching pools, the statements handed down regarding major decisions affecting the Bitcoin system seem eerily central and authoritative. was this kind of power considered initially and is thus balanced now, or was Bitcoin intended to be strictly p2p initially?

There's a conversation on cryptography@metzdowd.org shortly after the release of the Bitcoin paper that touches on this tangentially:
James A. Donald - Sun, 02 Nov 2008

For transferable proof of work tokens to have value, they must have
monetary value.  To have monetary value, they must be transferred within
a very large network - for example a file trading network akin to
bittorrent.
To detect and reject a double spending event in a timely manner, one
must have most past transactions of the coins in the transaction, which,
naively implemented, requires each peer to have most past
transactions, or most past transactions that occurred recently. [...]

Satoshi Nakamoto - Sun, 02 Nov 2008

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

From the word choice used here, a datacenter of machines using a single server to construct blocks is intended. However, many different parties using the same pool server is not contemplated.
Of course, that doesn't mean that pooled mining is wrong - just that it wasn't anticipated.


Should you protect your Bitcoin address like your credit card number? Today, I recieved this scam email:

  We have reached the biggest milestone in our history – over a million wallets.

  https://[removed] will celebrate with some big prizes.

  In October 2013, the lucky user who created the 500,000th wallet was rewarded with 10 BTC.

  Read more about this: http://[removed]

  We have discovered that you created the wallet with number 1.000.000

  [removed] want to reward you with 50 BTC.

  To prove that you are the rightful owner of the lucky wallet,
     please reply to this email and send us your mnemonic ( the long string of words generated randomly when your account was created)

  After verification, your wallet will be credited instantly with the 50 BTC.

  Thank you that you have chosen https://[removed]

I am guessing this is a scam as (a) it was sent to two separate email addresses I have, (b) the sender's email is in no way affiliated to the websites listed in the email and (c) I don't think anyone is willing to just give away 50 BTC which is close to $42,000 USD. I was wondering if I were to give them my Bitcoin address, what would happen next? Would they be able to use it like a credit card number? Or would they just be asking for more personal information?

A bitcoin address is not like a credit card number. You can safely give your bitcoin address out publicly.

What the email is asking for is something you should never give out publicly: the mnemonic that you use (e.g. if you use Electrum, they have a 12-word mnemonic code), from which you can calculate your private keys. With this, they can easily steal all bitcoins on any address that was generated using that mnemonic.

If they actually wanted to know that you are the owner of an address, they could ask you to sign a message. There's not normally much of a reason to do this, though: I don't see a scenario in which a signed message is needed in order to give you money, instead of just the address.

If they actually just wanted to send you money (as they claim), all they need is your address.


Using bitcoin in a startup company We are a start up company going to open an online shopping website. Our CEO wants to incorporate Bitcoin as our payment method. How can we set up a Bitcoin network?

You can use one of the merchant solution providers, such as:
coinbase, BitPay, for generating addresses per payment (as paypal does) redirects / serve the client with payment request at 3rd party .
or, you can handle payment process inhouse by generating address for each payment and saving the pk / HD wallet will take much longer and develop time to do.


"command not found' while installing dependencies While installing dependencies for compiling an altcoin wallet on VPS for run a Masternode - using Ubuntu 16 I run into this fatal error

In file included from alert.h:9:0,
                 from alert.cpp:5:
serialize.h:19:48: fatal error: boost/type_traits/is_fundamental.hpp: No such file or directory
compilation terminated.
makefile.unix:200: recipe for target 'obj/alert.o' failed

whilst installing dependencies - the installation gets stuck on the last line - command not found

:~/Rupee-Core/src# libdb++-dev libboost-all-dev libcrypto++-dev libqrencode-dev libminiupnpc-dev
libdb++-dev: command not found
root@RUP2:~/Rupee-Core/src# libgmp-dev libgmp3-dev autoconf autogen automake libtool

does anybody have a suggestion what I could do to resolve this?

Not

libdb++-dev libboost-all-dev libcrypto++-dev libqrencode-dev libminiupnpc-dev

but

sudo apt-get install libdb++-dev libboost-all-dev libcrypto++-dev libqrencode-dev libminiupnpc-dev

Those are dependencies. install tells apt-get to download and install those dependencies. sudo gives apt-get admin permissions.


Why do we need block hashes in blockchain? I believe there are around 3 types of overall hashes that we deal with in Bitcoin.

block hashes
Merkle tree hashes (makes transactions tamper proof by hashing them up to the Merkle root)
public-private key hashes (used as part of the UTXO model to generate addresses derived from the public key)

I get the functionality of all hashes other than 1st.
Is it only there for reference ?? We could have used block height as block reference and traversal and added nonce in that for our POW requirement.

on functionality:

from Andreas book "Mastering Bitcoin", Chapter 7:

  The primary identifier of a block is its cryptographic hash, a digital
  fingerprint, made by hashing the block header twice through the SHA256
  algorithm. The resulting 32-byte hash is called the block hash but is
  more accurately the block header hash, because only the block header
  is used to compute it...

This block hash is a reference to a previous block hash, which connects this block to the previous block in the blockchain.

  Is it only there for reference ??

no, it's a pointer to the previous block, so the chain can be established. As in the linked article:

  one can not simply create a block "isolated" from the blockchain
  and then just "insert" it in the blockchain to win the reward
  it's necessary that a previous block is known before a new valid one is created.

  using block height?

again from Andreas book:
A block’s block hash always identifies a single block uniquely. A block also always has a specific block height. However, it is not always the case that a specific block height can identify a single block. Rather, two or more blocks might compete for a single position in the blockchain.

Further down, he mentions, that this comes into play when discussing forks.


Merkle root vs message digest? My question is in relation to the operational difference between a merkle root and a plain old message digest.

To calculate a merkle root I need to complete the following steps :

hash each transaction in a block
create a merkle tree from all the hashed transactions
work back up the merkle tree hashing pairs of transactions until I calculate the merkle root

To create a plain old message digest I would do the following :

Take all transactions in a block hash them at the same time to create a message digest

My question is, how is a merkle root more beneficial from an operational standpoint than a plain old message digest?

Initially, they appear the same, only considering that there is a hash included in the block.

A Merkle Tree is more efficient to prove a transaction is included in a block since otherwise, it is necessary to have and hash each transaction to prove a transaction is included using a message digest, so a full node can do this, but an SPV client (and a pruned node looking outside the blocks it has kept) cannot.

There is some more information on how this works in these answers: Merkle Root and Merkle Proofs


How do honest mining pools generally divide their rewards? I've been reading a little about mining pools and the Stratum protocol for requesting work from mining pools and it got me to wondering.  How does an honest mining pool divide up rewards?  I see that the protocol allows for workers to request work from the pool, but how does the mining pool know how much work each worker has done?  As far as I can tell, workers only report back to the mining pool when they have "solved" a hash and want to submit their answer for consideration.  But what if that worker just lucky and there are other miners who have done  much more work -- do they get paid the same?  Similarly does a miner who is in the pool but hasn't solved anything get paid anything?

Mining pools use a system that is based on shares. Shares are blocks with proof of works for a different difficulty than the network difficulty. Mining pools will set the difficulty for a given miner to be something that is reasonable for it to achieve. So when that miner mines, it is looking for a block hash that meets the pool difficulty. Once it does, it submits the block. That submitted block, although likely not valid to the Bitcoin network, meets the pool difficulty and is known as a share.

So mining pools will count the shares and give weight to each share based upon the difficulty that it was mined at. In this way, the mining pool can determine how much work each miner has done on average and pay them accordingly once a block is actually found.

Blocks are found when a share meets both the pool difficulty and the network difficulty.


How prevalent are multisigs? There seemed to be great demand for multi-siganture transactions to be provided, but they don't seem to be so popular now that they are available.

What percentage of transactions are multisig since their release?

You can find the stats of different transaction types here: http://webbtc.com/stats


Energy backed cryptocurrency? Would it be possible to create energy backed cryptocurrency?

There are some earlier theories of creating energy backed money. However the instant challenges I see are

Energy (as an electricity) is globally not transferable, storeable, and must be consumed immediately. It would only work if buyer and seller are connected to the same grid.
The value of energy varies highly depending on the location. E.g. 1 kWh in Africa is much more worth than 1 kWh in New York. The problem of unified exchange rate, e.g. like with gold, would make it very hard to the medium for exchange of value.

Thus, energy backed money may not work in a sense that "1 kWh = 1 coin", because energy lacks the properties to become a transfer of value? But are there other aspects one could use cryptocurrency to bind it to the value of energy?

Well, in a certain sense, electricity can be stored, if you're generating it via coal, natural gas, hydro, or nuclear power plants. (You store it by not generating it in the first place.)

You could define a unit of currency as being a note issued by a power company saying, "IOU one megajoule." Cross region commerce would be handled by finding a middleman to exchange, for example, an Xcel IOU for a GDF Suez IOU.

There would be some problems with this approach. First, Bitcoin has a reliability of 99% to 99.99%, depending on how you define it. That's not reliable enough in a lot of contexts. For example, imagine if a hospital was unable to buy power for an hour each year.

Second, the exchange rates between the various IOUs will change based on speculation and changes in the fuel markets, so what you can buy with your money wouldn't stay stable week-to-week. For example, imagine if you were paid in Delmarva IOU's because you worked for a corporation headquartered in Delaware, but you lived somewhere where you needed to pay your bills in Xcel IOU's.

Theoretically, you could do this. I'm not sure that you'd want to, though.


Can each Bitcoin and Satoshi be uniquely identified? I'm pretty sure I've read somewhere that BitCoins have an "address", so they can be uniquely identified.

What I want to know is:

Does each Satoshi have it's own unique identity?
How is the identity of a Satoshi formatted? (providing 1 is true)

Bitcoins and satoshis do not have unique identities.

However, Bitcoin balances are stored in uniquely identifiable "transaction outputs" that can only be spent by the owner of the recipient address.

  Example:
   Alice sends Bob 1 BTC, Bob uses it to send another payment.

  When Alice sends Bob a payment of 1 BTC, she signs a transaction that deducts 1 BTC from her funds and creates a new transaction output that is worth 1 BTC and can only be spent by Bob, the owner of the recipient address.

  Bob now wants to send 0.4 BTC to Charles. The transaction output from Alice's transaction is now used to fund this new transaction. The transaction creates two new outputs: One with 0.4 BTC that is associated with Charles' address, and one with 0.6 BTC associated with Bob's address (it is the change). The first transaction output (from Alice's transaction) is consumed by the transaction.

Unspent Transaction Outputs are identified by the (unique) hash of the transaction they were created in, and their position in the list of outputs.


BitcoinCore Password crash I have a Bitcoin Core wallet. 4 days ago my password worked. Now I can't send bitcoins from my wallet: the password is wrong.  What happened?  Please help, all my money is there.  I did not change the password phrase and I am sure I remember my password.  How can I resolve my problem?

Try caps-lock ?

If you do not know your password it is very difficult. If you search there are other questions like this one discussing software to possibly recover the password.


Double Spending before confirmation What's to prevent someone from using bitcoin at a store like subway and double spending to buy the sandwich before a confirmation is made? Since subway obviously isn't going to wait for a confirmation, can't a person send bitcoin to subway and at the same time send that bitcoin to another address?

RBF exploits are possible for 0 confirmation transactions.

The risk/reward is tiny so some merchants will accept small transactions and make delivery without waiting for a confirmation first.

99.9% of the people who have both the competence and lack of morality to double spend in this manner would not waste their time on such a low value theft.

All merchants should wait for (at least) 1 confirmation of possible but the risk is too small for many people to care when selling sandwiches. Any merchant selling a yacht should be waiting for multiple confirmations anyway so the RBF exploit should not be relevant for high value transactions.


Bitcoin extortion threat for address 14poC1Jg97vuvsyoKSZYz7h276LoAZcrtn? I have received an email saying my computer was hacked a long time ago with a threat of realeasing personal details unless I pay a ransom to a bit coin address: 14poC1Jg97vuvsyoKSZYz7h276LoAZcrtn

Is there any way to check if the this is a hoax?

It is a well-known hoax, ignore it.

https://blog.malwarebytes.com/cybercrime/2019/02/sextortion-bitcoin-scam-makes-unwelcome-return/

It never hurts to check your antivirus protection is up to date and that you have offline backups of important documents/photos etc (and test that you can recover from those backups)

It doesn't hurt to reconsider how you compose and use your passwords for online services (shopping banks, email, amazon, ebay, etc). Change passwords associated with websites that have had a data-breach. make sure you don't use the same password for more than one website. Make sure you use strong passwords (e.g. long random ones generated by a carefully researched and carefully chosen reputable password manager)


Is the otherwise promising Ripple set to become a great currency fraud? The Ripple system is really interesting, but on one point I can't help thinking part of it is a great scheme to make the founders (and OpenCoin) ridiculously rich. The reason that makes me wonder is that 100 billion XRP were initially created, and of these 20 billion are kept by the founders and 80 billion were given to OpenCoin (from their wiki). OpenCoin plans to give away some XRP, and sell some XRP, but it's not clear in what proportions or how much. No new XRP will ever be created, and the value of XRP will increase gradually as more people demand it for transactions (and XRP is the native currency of Ripple and will be the most convenient transaction medium inside Ripple). XRP also have intrinsic value in that they are strictly necessary to perform transactions, and because XRP used for transactions are destroyed the total amount of XRP in the system will decrease steadily.

So we have a system where the founders and OpenCoin have control over almost all purchasing power. Moreover, because of this, they can keep exchange rates of XRP as high as they like by keeping supply low. If Ripple would take off and be widely adopted, the founders and OpenCoin would get unimaginably rich because of the big shares in the fiat currency they created.

It makes me think of the famous quote: "Give me control over a nation's currency and I care not who makes its laws." It doesn't apply in full because the founders and OpenCoin won't create more currency, but owning all currency from the beginning will have the same effect over the foreseeable future.

So is this nothing more than a smart fraud that's incredibly big in scope? Are there any indications that the supply of XRP will get some kind of fair distribution?

Opencoin plans to give away 50 billion XRP. It is actually in Opencoin's best interest to make this distribution as wide as possible as the system will only be successful if it can gain a critical mass of users. Giving away enough XRP to keep the system as cheap as possible for as many people as possible for as long as possible is the only strategy they believe will work.

A lot of people have suggested possible nefarious schemes and conspiracy theories around Ripple. But you have to remember, if the Ripple payment network doesn't become popular, nothing else matters. It is simply a better strategy to give away lots of XRP as fairly as possible to drive adoption. Not to mention, not doing what they said they would do would reduce confidence in the system.

Billions of XRP will be distributed as widely as possible. The system will be fully open source. There will be no central authorities. That's what's in the founder's best interests, that's what's in Opencoin's best interests, that's what Ripple was designed to be, and that's what Opencoin intends to do.

The founders get 20 billion XRP. OpenCoin gets 80 billion XRP -- 50 billion of which can be given away to promote widespread adoption. That's the deal that was struck.

Note: I'm an employee of Opencoin and one of the architects of the Ripple payment system. I am speaking only for myself.


How exactly does SPV work? Here is what I have so far:

A mobile connects to a node using rpc.
The mobile then asks the node, to give him a set of transactions for a set of public keys.
The node, then looks for any transactions that match the public keys given and returns it back to the mobile.

The mobile can setup a bloom filter, so that some of keys included are not his?

Also, when the node receives a request, it needs to scan the blockchain all over again, to get the transaction history?

A mobile connects to a node using rpc.

Nodes don't connect each other using RPC. RPC is for node owners, and usually has a long password.

  The mobile then asks the node, to give him a set of transactions for a set of public keys.

Not exactly. First of all, block headers have a part that's named "Merkle root" that allows clients to check if a transaction was in the block. In theory, as described in the whitepaper, SPV nodes can keep block headers, and ask other nodes for Merkle proof of their transaction. In practice, it's more complicated. Currently 99% of the SPV nodes use BIP 37. Besides, better SPV methods such as BIP 157 and Neutrino are being researched.

  Also, when the node receives a request, it needs to scan the blockchain all over again, to get the transaction history?

Nodes do need to scan the whole blockchain for a transaction if they don't know its block height, unless they use txindex=1, etc... If they do, accessing it is trivial.


Where is seed in Bitcoin Core in comparison to Bread Wallet Im new to Bitcoin. I know the main software of bitcoin is Bitcoin Core. Recently i started using an iOS wallet called Bread. Its very simple! It gives me a 12 word key and says your master private key can extract from this and no need to backup your wallet as a file.

My question is: i readed that Bitcoin Core in the new versions is an HD Wallet. But it never gives me a seed like bread. Im confused.

I have an assumption but i dont know its right or not:
My master private key stored in a file unlike bread. I have to encrypt my walled from bitcoin core settings menu and the from file menu choose Backup Wallet and save it. In fact, in the future, i have to import that file and enter encryption passphrase that i created in the encryption step and the software fetches my private key from that file and load my entire wallet from blockchain. In bread i enter that 12 word and bread creates my private key and so on... in bitcoin core i need backup just one time. In Bread i have to write down my seed and in Bitcon Core i have to backup both passphrase and wallet file.
is this true? bitcoin works like this?

As i know i cant import wallet i created in Bread to bitcoin core. Each software has its own seed to private key mechanism. Is this true? I want to use bread and Bitcoin Core both in my pc and mobile.

In Bread i have to write down my seed and in Bitcon Core i have to backup both passphrase and wallet file. is this true?

Yes.

  Each software has its own seed to private key mechanism. Is this true?

No. What you call the "seed" is actually called the mnemonic. Most wallets that give you a mnemonic use BIP 39. BIP 39 specifies how the mnemonic should be created and how to convert the mnemonic to an actual seed value.  Most HD wallets then use BIP 32 to convert that seed into your private keys

Bitcoin Core implements BIP 32, but not BIP 39.


Has anyone used Bitstamp international bank transfer? I want to use bitstamp to sell my bitcoins and receive USD in my bank account in Pakistan through wire transfer. Has anyone used this service at bitstamp? How long does it normally take and did you experience any hurdles in the process?
Also are there any alternative services like bitstamp which are reliable, offer good conversion rates and low fees for international transfer?

I used it, and it worked fine. You could also check out telenor, I think they are selling bitcoins in Pakistan, so no need to trade abroad. The premium may be worth paying given the rising value of the coins i.e your $ buying power may diminish whilst your transfer is processed by the banks.


How much privacy does Lightning actually have? I can't find any information on what information is actually contained within a lightning transaction.
Lets say Alice wants to pay Bob on lightning and routes through R1, R2, R3 in the following order
Alice > R1 > R2 > R3 > Bob
I assume Bob needs to know information regarding the channel UTXO from Alice, otherwise how would Bob know that the channel is funded?
If this assumption is true, how is Lightning more private than Bitcoin? (except for the fact that nodes don't need to store the information on channel UTXO's [but they can if they want...])
If Bob is known amongst authorities as a common endpoint for whoever they are targeting, they can compel Bob to reveal if he received a payment which was funded from a channel with some known UTXO (they would know the channel UTXO from on-chain analysis of their tracking of Alice). If Bob is logging the information he's paid with, then he would have the ability to comply with this authority, effectively making this Lightning payment no more private than a Bitcoin payment. If Alice gave Bob some personal information in relation to the payment, this would completely dox Alice to authorities.
Also, does R1, R2, R3 also know the channel UTXO?
If the channel UTXO is not known amongst participants, how does the target channel validate that the source channel is funded?
Would appreciate guidance on this
Thank you

Bob only knows the channel R3--Bob and his other channels.
in particular due to the onion routing Bob has no way of knowing who send the payment or say anything about the channels of the sender (as Bob does not know the sender)
Routing only know their incoming and outgoing channel. So the only thing that R2 would know is that there was and HTLC offered by R1 and that it is supposed to be forwarded to R3.
With respect to your question of how does Bob know about Alices channel. As said Bob doesn't but you could invert the question. If alice wants to pay Bob, how does she know about the R3 - Bob channel? There are two possibilities. Either Bob specified a Routing hint in the invoice or she does so (with other channels on the path) with a probing trial and error approach. This is well described in https://arxiv.org/abs/2103.08576 where this was also used to probe for the balance values of channels. In that sense the information on Lightning Network is not strictly private.
However probing takes time and might be inacurate as there are counter measures to probing channel balances. (In comparison if you see something on chain it is pretty clear that this is the reality)


Could i build a mining rig with these parts? I have researched bitcoin mining for a while, and i have decided that i want to build a dedicated miner. Since i am very low on budget, I thought that maybe i could use an old computer that i have in my house for the motherboard and CPU requirements, and by only a GPU. My old computer has an AsusTek computer inc P5S800-VM motherboard, featuring an Intel Pentium 4 processor. Link:
http://www.asus.com/Motherboard/P5S800VM/

Is there a way to add an ATI GPU to this system and make it work as a miner? Thanks for any responses, and sorry if i was not clear enough - i am quite new to this field.

I have to say you did not research Bitcoin mining enough. Mining on a GPU is obsolete, reports say ASIC-based mining devices with x40 the performance have already started shipping.


What is [::]:0 address in bitcoin debug.log? I am trying to run and connect multiple nodes on a single machine, i.e different nodes using different ports. I am having trouble in connecting the nodes and making them talk to each other. While debugging, I inserted a LogPrintf("%s\n",addr) in the while loop of ThreadOpenConnections() in net.cpp file.

The output in the debug.log file is always [::]:0. What does this address mean ? Is it for localhost representation or something else ?

[::] is IPv6's version of localhost (0.0.0.0).


bitcoind json-rpc interface specification Is there any document out there on the internet describing how access the json-rpc interface of the bitcoind daemon? In my case, my application is written with C++, and I want access this interface with this language. In my Kubuntu system, I have run bitcoin-qt and it's listenning on port 8333. I create a bitcoin.conf file on my data directory setting an username and a password. Now I want to know how access this interface using C++.

ps.: I should note that I know about libbitcoin library. I ask for the specification because I am trying find a simplest approach, maybe allowing me write my code in only one or two source code files.

Send HTTP POST requests to the Bitcoin Core RPC server and you will get responses in JSON.


electrum CLI - 'daemon is not connected' I installed Electrum on my Raspberry Pi.

Then, I ran electrum create to make a wallet.

Then, I ran electrum daemon start to start the background process.

I'm currently trying to query the balance of my wallet (should be 0) from the command line using electrum getbalance

I get this error

[root@fish ~]# electrum getbalance
daemon is not connected

Daemon status:

[root@fish ~]# electrum daemon status
{
    "blockchain_height": 352760,
    "connected": false,
    "nodes": [
        "electrum.thwg.org:50002:s",
        "kirsche.emzy.de:50002:s",
        "ecdsa.net:110:s",
        "erbium1.sytes.net:50002:s",
        "electrum.drollette.com:50002:s",
        "eco-electrum.ddns.net:50002:s",
        "EAST.electrum.jdubya.info:50002:s"
    ],
    "server": "electrum.be",
    "server_height": 0
}

Note the "connected": false, field. What does this mean? Is it related to my node not working?

you need to run

electrum daemon load_wallet

load_wallet or other wallet


Are there valid transactions which are impossible to mine? Is it possible to have a bitcoin transaction T that is valid with a very generous transaction fee for which it is impossible for T to be included in the next block, or even in all subsequent blocks?

The block header contains a hash of the previous block header as well the hash of the merkle root of all transactions in the block. Can T exist such that including T in the block renders all possible nonce values for that block futile in solving the mining puzzle?

I'm guessing that the existence of such a transaction for any particular network configuration occurs with very low probability. Is there a proof which shows that such an event is unlikely or even impossible due to the cryptographic properties of the SHA256 hash function?

I think that the answer to your question is no, a transaction which makes every block it is included in invalid does not exist.

An important core property of a cryptographic hash function is that there is no discernable relationship between the input data, and output data. If such a relationship existed, then miners could 'cheat' by only creating blocks (input data) that would lead to a valid hash (output data) in the preferred range (lower than the difficulty target). In reality, we see that changing the input data slightly will drastically alter the output data, in a deterministic but unpredictable way.

And so I don't believe a transaction could exist, which would invalidate every block which it was attempted to be included in. Even if you create a block with just a coinbase transaction, and exhaust the nonce and extranonce space without finding a valid solution, the timestamp will still slowly increment, and each time it does you can search the entire nonce/extranonce space again. Probabilistically, since we expect an even, and random output value distribution from the hash function, after enough time, some combination of your transaction / the timestamp / the nonce and extranonce should lead to a valid block.

There is also lots of other data that can be included in a block, and altering any piece of it will affect the block hash as well. Murch's answer here tells us that lately there are ~2000 transactions in a block on average. For simplicity, lets assume that all transactions in the block are independent, so they could be included in any order. The number of permutations for the transaction ordering is thus 2000!, which is a huge number (~3.316 E +5735). For each of these combinations, the miner could exhaust the nonce space, the extranonce space, and then increment the timestamp and do it all again. This makes our number of possible arrangements even more enormous! Given enough time, and computational power, it becomes likely that a valid block hash will be found.

So, just from a probabilistic argument, I don't believe it is possible for the inclusion of some transaction to magically only create invalid blocks. Perhaps someone more well versed in the nitty-gritty details can offer a more thorough proof of this, but I think just the numbers alone, combined with the security properties of a cryptographic hash function, are reasonable enough proof.


How should a node deal with a block that is not connected to the chain? Suppose I am a node in the Bitcoin protocol and I receive a block that does not point to any  block in my current chain. Should I keep it on the side, waiting for missing intermediate ones? Should I propagate it? Should I just erase it?

The Bitcoin client used to download blocks without necessarily knowing if they could connect it to their current chain. If it couldn't connect a block to the genesis block, it would just keep it in memory. This was a waste of memory (up to 750 MB could be used up before it started dropping blocks) and bandwidth (if you drop a block that you need, that wastes bandwidth)

It does something smarter now, though. It builds a chain of block headers to the current tip of the chain, then downloads the block contents. Not only is this simpler, and more resource efficient, it also allows you to download multiple blocks in parallel. Blocks are written to disk as soon as they're downloaded.

Since there's no way that you will receive a block that you didn't ask for, the current Bitcoin client will drop the block and permanently disconnect from the peer that sent it.


What is the purpose of the 20 XRP cost to start a wallet? Does the money stay in the wallet or is it used to pay for something?

If it's used to pay, who does it go to?

If it stays in the wallet, am I allowed to take it out and drain the wallet later without any consequences?

Unlike a bitcoin receiving address, a funded Ripple wallet is a real thing on the ledger that has properties. This has advantages and disadvantages, but one of the disadvantages is that there's a cost associated with having one. To cover the costs imposed on the network, the XRP Ledger has a "base reserve" that is XRP that is not spendable or transferrable. You can use the reserve to pay transaction fees and, if the reserve drops, you can transfer out XRP to the new reserve level.

Some of the advantages of this scheme include:

The ability to change the key protecting an account without changing the receiving address.

The ability to configure an account for multisign and change the keys, signers, or quorum, again all without changing the receiving address.

Addresses can configure what assets they're willing to accept as payment and payments to them can automatically route through intermediary assets to find the cheapest path.

Accounts can place offers to trade one asset for another on a distributed exchange that follows deterministic rules.

The reserve goes up (currently by 5 XRP) for every additional object an account owns in the ledger (such as a trust line, offer, or escrow). You can reduce your reserve by eliminating these objects, but current rules do not allow the base reserve to ever be transferred or spent -- it covers the cost associated with recording the fact that the account has already performed certain transactions and without this recording, those transactions could potentially be replayed.


Why is the full Merkle path needed to verify a transaction? If I have transaction A and wish to verify that it is in the block, and I also have the hash of transaction B and the hash of the hashes of A and B, then can't I just hash A and then see if what I get by hashing A's hash and B's hash is equal to what is in the Merkle tree? Why do I have go all the way to the root?

If you have A, HB and HAB you can obviously check whether A fits. As Jestin noted this is essentially a full Merkle tree with two leaves.

However, as a thin client, you only have readily available the Merkle root (which is in the block header) and get told about A. The intermediate levels of the Merkle tree are not provided, therefore, to calculate them, you'd need the block's complete set of transactions.

Image via Mastering Bitcoin

So, for a thin client, we calculate the Merkle branch instead. For the Merkle branch, we just need the transaction's position in the block's transaction list and the hashing partners at each level, instead of the complete set of transactions. A Merkle branch is impractical to fake because it would require finding of a hash collision (which is not doable, or mining wouldn't work). So by going up the tree and combining our result with the respective hashing partner at each level, we finally get the Merkle root. Thus we can prove membership of the transaction in the block.

In the example image, you only need to provide the blue information to link HK to the Merkle root, whereas checking the whole Merkle tree would require all transactions from  A to P and the Merkle root.


How Bitcoin handles addresses collisions? Since the addresses are hashes of a public portion of a public/private ECDSA keypair, what would happen to two different people with different keys that hashes into the same address?
How would transactions to those addresses be handled?

Both people would have access to any funds in the address. Whoever is first to spend these funds wins.

Of course, it is extremely unlikely that there will be such a collision.


Can I recover funds where the wrong destination tag was used while transferring ripple to bittrex? Is a refund possible if i entered the wrong Destination tag and the right address while transferring XRP to my bittrex wallet.

Contact Bittrex immediately. They may be able to return the funds if the destination address doesn't map to a valid customer. But if it does, they probably already credited that customer and there is likely nothing that they can do.


Derive LTC Segwit (M-Address) private key from Trezor So I'm trying to get my head around this!

I've got my 24 seed for my Trezor.
I got my Segwit account for LTC (Address starts with M).
I also have the P2H equivalent for my address (Starts with 3).

How do I derive using the BIP39? I tried, and I ended up with addresses that start with L. (Legacy ones).

m/49'/2'/0'/0    --> this one is for M Segwit LTC
m/44'/2'/0'/0    ---> this one is for Legacy LTC

When you are deriving addresses, you are actually deriving private or public keys from which an address is derived. However addresses are actually an encoding of what type of script to use in the output, but private keys have no concept of what scripts are. So when you derive your keys, they don't specify what type of address to create. Each private key can actually correspond to multiple addresses.

To specify what kind of address to create, your wallet software must be able to understand what the derivation paths mean or be able to be told what kind of address to be created. Just using a derivation path for keys which were used to derive one type of address does not mean that all software will create the same addresses.

You will need to use a software that knows how to create the address type you want and then you need to be able to tell it to do that.


Hypothetical Scenario - Address collision with address with already confirmed outgoing transaction In a typical case of finding a collision with an address, as long as the private key provided has a consistent public key that hashes to the address, then the coins in that address can be spent. The problem is that this assumes the collided address only has incoming transactions, and never an outgoing transaction. This is because that means the public key was never revealed but the address still has coins. In order for a transaction to be valid, it has to have a valid public key to verify the signature.

My question is this: if two outgoing transactions are made for the same address but with two different public keys (found by a collision), can the second transaction be confirmed if the first was already confirmed? Logically, the "righteous owner" of an address wouldn't have two distinct private/public key pairs for the same address (excluding multisigs), because that wouldn't make sense. Do clients even store the public key of transactions if they already confirmed it?

Provided the second transaction is spending inputs that have not been spent, yes.

There is no logic or rule that checks to ensure public key uniqueness for an address. As long as you can fulfill the signature and Hash160 checks, the transaction is valid.


What are the parts of a Bitcoin Transaction "Input" script? All the terminologies I find seem rather confusing about what explains what and they usually miss a few steps.

Example: Transaction 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

Found at https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

Shows an "Input Script" of:

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

So, what parts of that are what, and how can I tell which parts are what in this transaction's "input script" as well as others?

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

Is a DER encoded ECDSA signature. I'll break it down:

  30

indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)

  45

is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.

  02

the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)

  21

of 33 bytes

  00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5

the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).

  02

another integer follows (s)

  20

of 32 bytes

  57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d

the 32 bytes encoding the s value

  01

this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".


How to keep transaction generating time down? I have a wallet for a service that's getting bloated, and whenever I want to send transactions they notably get slow. How do I prevent stuff like this? Can I just send all the funds to an address to merge the unspent inputs?

You can always send whatever you have in your wallet to another address in the same wallet.
Depending on the size of the transaction you might have to pay a larger fee than normal.


Crypto exchanges algorithms I have noticed that if I put a buy order up - for instance - on any not so heavily traded coin, if close to the highest bid, often within 20 secs the highest bid will try to beat me.
Or when I put it close to the lowest ask price, often it won´t take long till I get someone to sell it to me.
Before this there can have been hours with no activity.
To me, this does not look like bots that are set up to track MDA or other common strategies, but the exchanges own bots reacting to certain inputs.
Does somebody know more about the algorithms used by the crypto exchanges, which behaves this way?

Thanks in advance!

you're providing alpha to "high frequency market makers". Since they can tell that you are not a bot, they are assuming its a real bid, so they can bid on top of you and then they are now in a risk free position.

if they get hit, they will immediately place an ask at a price of:  last + (last-bid). they will wait hoping you will pay up, they may even entice you by placing another bid higher... then (within a couple of seconds) they will hit your bid, and take the small loss.

as long as the spread is much wider than the tic above you, they are in positive alpha.

in general, you should not try to play this game. just place "marketable" limit orders.. so buys at the best ask, and sells at the best bid, otherwise you are giving away your hand.


Where is the AES-256 key/ IV pair stored in wallet.dat file? I have created an encrypted bitcoin file. I know the password and I see the mkey in the hex dump. I would like to know where the AES key / IV pair are located in the wallet.dat file?

I imagine the Bitcoin-core source code may be a good guide to the layout of a wallet.dat file. You may need to find the source of the specific version of Bitcoin core that created (or last wrote) the wallet.dat file.

There is also https://en.bitcoin.it/wiki/Wallet which points you to various resources.

  The format of this file is Berkeley DB. Tools that can manipulate wallet files include pywallet.


Lost Litecoin wallet? Using Litecoin-QT

First I created wallet a. Then I sent 2 LTC to that wallet's public address.

Then I imported a private key in Litecoin-QT and wallet a was gone?! Aren't all .dat files  that has been used stored somewhere, or do they get overwritten everytime you import a new key to your wallet?

Importing a private key should not cause you to lose your wallet. If you import a private key and then restore from a previous backup, you may lose that key, however.


Any stress-tests done after 2015? I was considering running a small test using Bitcoin transactions when I ran into the stress-test / DDOS that Coinwallet.eu conducted in July 2015 (and maybe September too, I am not really sure) where they bombarded the network with small transactions.

Were there any similar tests done? Are their results available? I am trying to find more information on what happen to transaction propagation times, block propagation times, etc, in presence of high volumes of transactions. Pointers to the right directions will be highly appreciated.

P.S. I am studying the behavior of crypto networks, so testnet tests are not really representative, in general, because of their small scale and different bandwidth characteristics, to the best of my understanding.

The 2015 stress test aimed to hit 200MB of backlogged tx, they only hit 15MB as reported by coindesk.

Blockchain.info reports that the backlog of tx hit 120MB May 16th 2017. It's mostly been above 20MB for the last 60 days as of this post.

How big of a stress test is big enough for you?


From where can I import live cryptocurrency market values into my webpage? I am planning to build a webpage where a user can enter his/her stock of various cryptocurrencies, and the webpage should display the current market value (in USD) for each of the cryptocurrency he/she has chosen.

I was wondering from where (which website/database) I can import the live market value for cryptocurrencies, so I can use the values in my website script?

Thank you very much in advance.

Take a look here: https://blockchain.info/api

https://blockchain.info/ticker gives you a json-object with recent data.


Was it always required for the Coinbase transaction to be the first transaction in a block? The user tempo mentioned on another topic:

  "At least in the early protocol versions it was possible to put the coinbase transaction not on the top of the outputs."

I have never heard about this before. Was the placement of the Coinbase transaction more flexible in earlier days or was it always necessary to put it as the first transaction in the block?

This is not true. Code and code comments in v0.1.5 (the oldest tagged version in git) enforce that there always is a coinbase transaction and that it must always be the first. There cannot be a coinbase transaction elsewhere in the block. Coinbase transactions are defined as transactions with one input whose previous transaction hash is all 0's and whose previous output index is -1 (because it is an unsigned int, this becomes 0xffffffff).

You can also find a copy of the original 0.1.0 source code and find the same code and comments in the same place in main.cpp.


Explanation of what an OP_RETURN transaction looks like How is OP_RETURN used and why was it introduced in the first place?

Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN.

Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they could take advantage of the irreversibility of the blockchain. Imagine for instance you wanted to write a contract and place it in an unchangeable location that at any future date one could go back to verify it existed. You can do this by using the blockchain. You add some bits to the transaction's scriptSig value that don't alter the end result of running that script, but allow you to store information like “I hereby declare to give asset A to address XYZ at time UNIX_TIMESTAMP”. There were even stranger ways people would add extra bits, like including it in the BTC value of an output. Some members of the community did not like this, as they saw these extra bits as polluting the blockchain. The extra bits were a network efficiency concern because more bits meant larger block chains and more of an onus on those who are running full nodes, and it was also a community consensus concern because they thought “we all implicitly agreed to store financial data in the blockchain, which is important to everyone, but we did not agree to store data like small text messages and invoice text”.

To reach a middle ground in these opposing views, the core-developers made the opcode OP_RETURN a valid opcode to be used in a bitcoin transaction, which allows 80 arbitrary bytes to be used in an unspendable transaction. A good explanation of this can be found here:

https://bitcoinfoundation.org/bitcoin/core-development-update-5/

Later in February 2014, the bytes count was reduced from 80 to 40 bytes. This change is documented in the link below. Note that in this pull discussion we learn that no more than one output with OP_RETURN can be included in a single transaction:

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

Now that we’ve got the reason behind OP_RETURN down, let’s look at an example of OP_RETURN. I used chain.com’s API to find a transaction which has an OP_RETURN in its scriptSig. That tx’s hash is

8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684

Make sure you are connected to a fully-loaded bitcoind node, and run this command:

$> bitcoind getrawtransaction 8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 1

which will give you this output:

{
"hex" : "0100000001c858ba5f607d762fe5be1dfe97ddc121827895c2562c4348d69d02b91dbb408e010000008b4830450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a0141045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4ffffffff020000000000000000156a13636861726c6579206c6f766573206865696469400d0300000000001976a914b8268ce4d481413c4e848ff353cd16104291c45b88ac00000000",
"txid" : "8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "8e40bb1db9029dd648432c56c295788221c1dd97fe1dbee52f767d605fba58c8",
        "vout" : 1,
        "scriptSig" : {
            "asm" : "30450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a01 045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4",
            "hex" : "4830450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a0141045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.00000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_RETURN 636861726c6579206c6f766573206865696469",
            "hex" : "6a13636861726c6579206c6f766573206865696469",
            "type" : "nulldata"
        }
    },
    {
        "value" : 0.00200000,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 b8268ce4d481413c4e848ff353cd16104291c45b OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a914b8268ce4d481413c4e848ff353cd16104291c45b88ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1HnhWpkMHMjgt167kvgcPyurMmsCQ2WPgg"
            ]
        }
    }
],
"blockhash" : "000000000000000004c31376d7619bf0f0d65af6fb028d3b4a410ea39d22554c",
"confirmations" : 2655,
"time" : 1404107109,
"blocktime" : 1404107109
}

Now, look at this transaction’s list of outputs, in particular the 1st one. By referencing the Bitcoin Wiki’s page on Script, Bitcoin’s stack-based programming language, we can see here that the OP_RETURN opcode is represented by the hex value 0x6a. This first byte it followed by a byte which represents the length of the rest of the bytes in the scriptPubKey. In this case we see the hex value Ox13, which means there are 19 more bytes. These bytes comprise the arbitrary less-than-40 bytes you are allowed to send in a transaction marked by the OP_RETURN opcode. If you pop the message bytes into a UTF8 decoder, you’ll see that

636861726c6579206c6f766573206865696469

becomes “charley loves heidi”. Aw! It’s almost like a digital version of a couple’s romantic heart tree carving. Now you understand at a byte level how OP_RETURN is supposed to work. You can write software now that searches for the OP_RETURN opcode in an output’s scriptPubKey, and use it to verify a contract or some other digital asset.


What is the required input for python-bitcoinlib getrawtransaction command? I am running a bitcoin node on my machine, fully synced with RPC commands enabled, rpc server live and txindex=1.

In the command-line I can run the following RPC call and obtain the information about the transaction I require. I am using the cli as I need to process 2.5 million transactions.

./bitcoin-cli decoderawtransaction $(./bitcoin-cli getrawtransaction b601fc820d66b6516f89557fba9b40943df962de96b914547dec72b0f047c2f3)

Which returns a JSON output of the transaction.

However, when run with the python-bitcoinlib library it seems to give the following error message

import bitcoin, bitcoin.rpc
bitcoin.SelectParams("mainnet")
rpc = bitcoin.rpc.Proxy()
rpc.getrawtransaction("b601fc820d66b6516f89557fba9b40943df962de96b914547dec72b0f047c2f3")

  InvalidParameterError: {u'message': u'parameter 1 must be of length 64 (not 128)', u'code': -8}

What am I doing wrong, isn't b601.. the transaction id?

Edit: As per comment
I fixed it by replacing rpc=bitcoin.rpc.Proxy() with rpc=bitcoin.rpc.RawProxy(). But I would still like to know why the previous fails.

getrawtransaction requires little endian format of the trxid, like:

import bitcoin.rpc
from bitcoin.core import lx
p = bitcoin.rpc.Proxy(service_url='http://usr:pa@ip:port')
trxid = lx('7e195aa3de827814f172c362fcf838d92ba10e3f9fdd9c3ecaf79522b311b22d')
rawtrx = p.getrawtransaction(trxid)
print(rawtrx)

Comments from Mr Peter Todd on that:

https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2pkh-txout.py#L41


Cryptocurrency Exchange Technical architecture? How to build it? (Developer Point of View) I'm a softawre developer & newly involved in Blockchain Technology.

  I need information about How Cryptocurrency Exchange Technically work?
  i.e Buy ETH using BTC or exchanging any coin with another coin etc.

I know all the other terms/things needed for exchange like, Legal, security, KYC, peer to peer etc.

I search many articles but didn't found any technical architecture. found following

  There are readymade API's like block.io, chain.com, blockcypher.com etc who provide such thing.
  but want to develope it from core ie bitcoind Github.

I have good conceptual knowledge of Blockchain, Solidity etc.
Working with Bitcoin Core for creating new address, sending BTC to another address vai CMD prompt.
Able to implement Block Explorer etc.
Able to create new Coin/Currency in Solidity using ETH Compiler.

What I really need is Direction & path to follow.
As the technology is new, resources are very few. Any technical help I really appreciate.

Thank you, Have a great day.

There is opensource asset exchange called Peatio written in ruby. You can look into its source code to see what happens with assets during their lifetime there.

Mainly there are 3 steps for exchange:

Deposit - put real coins to exchange's accounts
Exchange - change coins, by changing just values of accounts' balances
Withdraw - send real coins from exchange's accounts to end user

When user sends deposit request, exchange generates new address (sends rpc request to btc node), and assigns it to deposit entity in db. User have to send sufficient amount of btc, to fulfill deposit. When special daemon watcher finds incoming transaction to the address assigned to some deposit entity, it compares incoming amount with required one and waits for confirmations. If there are enough btcs and confirmations - daemon increases amount of user's account balance.

Then, during user's exchanges, exchange engine just changes numbers in db, so no real transactions are provided. This allows very fast fast and network fee free exchanges.

When user decides to spend bitcoins from account, he sends withdrawal request to exchange. Exchange checks user's balance and if there are enough coins, sends them from its wallet to user's address and decreases user's balance

In such system security of the main server is critical. All coins are stored on wallets of the system and can be spent by it. So cold wallet is usually used in such exchanges. Nearly 90% of total amount of all coins are sent to some secured wallet: hardware wallet or at least wallet, that is stored on a system that doesn't have internet connection. When there is not enough coins on hot wallet to create withdrawal, alert is sent to admin, and he manually sends some coins from cold wallet to hot.

If you don't want to allow trading, and just want exchange, you can remove Exchange step, and create withdrawal just after deposit fulfillment. But then you have to determine price of the pair.

This is not the only approach to asset exchanges. There are also approaches when users control their wallets on exchange, and approaches when decisions to change user's balance are taken by several nodes together.


DumpMempool() and LoadMempool() in src/validation.cpp My understanding is that DumpMempool() saves the memory pool state (unconfirmed txs received from other peers and if any txs broadcasted from this node) to disk and LoadMempool() is used if this state is required. Is this correct or how does this work and what should be my approach if I am testing Dandelion (right now trying to solve conflicts)?
https://github.com/bitcoin/bitcoin/blob/3caee16946575e71e90ead9ac531f5a3a1259307/src/validation.cpp#L5139
This is what I see in mempool.dat file:

What exactly is happening in src/validation.cpp and what is saved in mempool.dat, when is this data required, what happens if there is an issue saving or loading data from the file?

What exactly is happening in src/validation.cpp and what is saved in mempool.dat, when is this data required, what happens if there is an issue saving or loading data from the file?

The current mempool of a node is kept in RAM during node runtime. As node operators, miners, and users we want transactions that are in our mempool and our own priority for these transactions to be persisted across node restarts. Imagine you are a mining-pool operator and you lose the contents of your mempool. After a restart, you'd be at a big disadvantage compared to other mining-pool operators who can choose from a broader set of transactions to include in their proposed block.
The mempool.dat file is a snapshot of your mempool at a given time. It's read with LoadMempool() on node startup and transactions are added to the node's mempool. On node shutdown or via the RPC savemempool the DumpMempool() function is triggered. This writes a current snapshot of the nodes mempool into the mempool.dat file.

Warning: The file format is internal to Bitcoin Core and can change without deprecation nor prior notice. The following describes the contents of a version 1 mempool.dat file (see the constant MEMPOOL_DUMP_VERSION).

The mempool.dat file contains a header that consists of a uint64 version number and the number of transactions contained in the file stored in a uint64 as well. This is followed by a vector of mempool entries. An entry consists of the raw transaction, the time it entered the nodes mempool as int64, and a fee-delta as uint64 used for manual transaction prioritization for miners. The vector of entries is followed by a serialized map of txid -> amount which stores miner transaction prioritization information as well.
On start-up, the Bitcoin Core node tries to import the transactions in LoadMempool(). Some transactions are ignored during import:

transactions that expired in the meantime (transactions default to expire after two weeks unless the node configuration is changed).
transactions that already confirmed in the meantime
transactions that are already in the mempool (e.g. a peer already send it to us before we could import it)

Usually, something like this can be found in the debug.log file:
Imported mempool transactions from disk: 463 succeeded, 10 failed, 0 expired, 0 already there..

If the file is damaged or does not exist no transactions are loaded to the mempool. If the file can't be written during a shutdown, then the node simply can't load any transactions during its next start-up. This is only a real issue for mining-pool operators, but not normal users.

I've held a presentation on theLoadMempool() and DumpMempool() functions at the 2019 Chaincode Sumer Residency. The slides can be found in Google Slides or as PDF.


Data about number of block mined + stale blocks per day in Bitcoin? I am wondering if there is any easy way to get number of mined blocks per day + number of stale blocks per day for the last three month e.g.,?
I could not find such data on Blockchain.info

In Ethereum, however, Etherscan provides these, see: https://etherscan.io/chart/blocks and https://etherscan.io/chart/uncles

Any help about getting such data for Bitcoin?

To my knowledge, there is no high quality data source for this.

Blocks mined is fairly simple to check, as that is simply the main chain's progress.

Stale blocks is harder for Bitcoin and Bitcoin based currencies. Unlikely ethereum's uncles, references to stale blocks are not stored anywhere, and after a better chain exists, propagation will not take place, so many nodes do not see a stale block at all. The only way to collect data would be to run multiple nodes, connected to as many different peers are possible, and monitor the logs for chain tip reorganizations. As far as I'm aware, no one is currently doing this, and if they are it is not offered as a publicly available dataset.


Does running an alternative full node implementation benefit the Bitcoin network? I've seen discussions suggesting that
a monoculture of full nodes
is a risk to the security of Bitcoin.

The accepted answer
to the question
"What benefit does a non-mining client provide to the network?"
gives an explanation with regard to full nodes in general.
I'm interested in alternative full node implementations in particular,
ignoring any wallet or wallet API capabilities.

Let's assume that
one or more alternative full node implementations
can run the protocol reliably and accurately.
What are the short-term and long-term benefits of running such nodes
compared to running the Satoshi client?

Edit: See also "What's the status of alternative full node implementations?"

If all bitcoin nodes run the Satoshi client then they are all affected by the same bugs. So other implementations of the protocol will certainly help in this regard. Imagine that the Satoshi client was affected by a bug that when a certain date is reached or a certain event occurs, it somehow causes the blockchain data to be corrupted or even deleted. The bitcoin network could even grind to a halt. This is quite an extreme case but it's just to give you the idea.
If alternative implementations were widely used, only part of the network would go down.
All implementations only have to agree on the bitcoin protocol, so they would still be vulnerable to bugs in the bitcoin protocol itself, but there are hardly any bugs in it, and even those could be fixed by changing or extending the protocol.
There are some known bugs in the bitcoin protocol, like for example its inability to handle dates bigger than 2106, but it's not considered a serious problem and by the time that date approaches a solution will probably be found.


Why is my mempool count so much lower than that of block explorers? I have been running a full node for about two days.  I wanted to get a list of all mempool txs (using getrawmempool false), and found that it only came back with around 3,000 even though all the block explorers are currently showing around 12,000.  I understand that mempools will differ between nodes, but this seems like a very big difference.  Can I do anything about this?
My getmempoolinfo:
"size": 1985,
"bytes": 3458091,
"usage": 10785216,
"maxmempool": 300000000,
"mempoolminfee": 0.00001000,
"minrelaytxfee": 0.00001000

What does bitcoin-cli getmempoolinfo spit out?

You may want to increase the maxmempool config value.


Web Wallet difference I have some questions about the listed Web wallets. Can someone please help me understand?

The bitcoin.org page for some web wallets says "Shared control over your money" (e.g. BitGo, BTC.com) while for Coin.Space says "Full control"

What's the difference?
Why does only one Web wallet (Coin.Space) give you full control, why not others?

2.

Why are these wallets not listed on bitcoin.org/en/choose-your-wallet:
StrongCoin,
Blockchain.info,
Jaxx

Why are these not listed on bitcoin.com/choose-your-wallet:
Coin.Space,
Xapo

Some web wallets (e.g. Coin.Space, Coinbase) say "Vulnerable environment" while others do not
(e.g. BitGo, BTC.com). Some like Jaxx list "Secure environment".
What is the difference?
Some says "Remote app", some do not.
What is the difference?

I’d be thankful for your help!

Additional Questions (from comments):

After reading about HD, BIP and understanding (somewhat) how blockchain.info's (bc.i) recovery works, I looked at a few multi-sig wallets briefly: BTC.com, BitGo, GreenAddress (GA). It appears that their recovery would be more troublesome compared to a mnemonic phrase method. Especially, the mention of "nLocktime" by GA was lost on me. I'd love your thoughts/feedback please.
About your comment: "can easily be stolen by the wallet provider". Is it because they know the mnemonic phrase? Is it that they generate it so they know it? If so, would you please recommend a wallet that is not easily stolen, but gives full control of key and easy to recover? I suspect with multi-sig, one would be dependent on pre-signed transactions being sent (by the wallet company), which may not happens if it suddenly disappears. Please correct me if I've completely misunderstood things.

What's the difference? Why does only one Web wallet (Coin.Space) give you full control, why not others?

Click the question mark icon next to each field and it will give you a more detailed explanation of what that qualifier means. For example, "Shared Control over your money" says this:

  This wallet requires every transaction to be authorized both by you and this third party. Under normal circumstances, you can regain full control over your bitcoins using your initial backup or pre-signed transactions sent by email.

"Full Control" says this:

  This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds. You are however still responsible for securing and backing up your wallet.

  Why are these wallets not listed on bitcoin.org/en/choose-your-wallet: StrongCoin, Blockchain.info, Jaxx

Bitcoin.org has a listing policy for wallets. Wallets must meet certain criteria for security, usability, and privacy in order to be listed on the website. The full criteria is available here: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/managing-wallets.md. Wallets which do not meet those criteria are either not added or are de-listed (as in the case with blockchain.info).

  Why are these not listed on bitcoin.com/choose-your-wallet: Coin.Space, Xapo

AFAIK bitcoin.com does not have any criteria for a wallet to be listed. Presumably wallets are not listed there because no one has bothered to ask them to list a wallet.

  Some web wallets (e.g. Coin.Space, Coinbase) say "Vulnerable environment" while others do not (e.g. BitGo, BTC.com). Some like Jaxx list "Secure environment". What is the difference?

Again, clicking the question mark icon will tell you. For "Vulnerable Environment", it says:

  This wallet can be loaded on computers which are vulnerable to malware. Securing your computer, using a strong passphrase, moving most of your funds to cold storage, or enabling two-factor authentication can make it harder to steal your bitcoins.

For "Secure Environment":

  This wallet is loaded on mobiles where apps are usually isolated. This provides a good protection against malware, although mobiles are usually easier to steal or lose. Encrypting your mobile and backing up your wallet can reduce that risk.

  Some says "Remote app", some do not. What is the difference?

For "Remote App":

  This wallet is loaded from a remote location. This means that whenever you use your wallet, you need to trust the developers not to steal or lose your bitcoins in an incident on their site. Using a browser extension or mobile app, if available, can reduce that risk.

  It appears that their recovery would be more troublesome compared to a mnemonic phrase method. Especially, the mention of "nLocktime" by GA was lost on me.

It can be more secure because in order for someone to steal your Bitcoin, they would need to compromise more than just your mnemonic, they would also need to compromise whatever two factor authentication you have set up in order to spend your coins.

The nLockTime thing is a special transaction which cannot be confirmed until after a certain date or block height. This transaction is for the possibility that GreenAddress becomes unavailable for some reason but still allows you to access your money.

  About your comment: "can easily be stolen by the wallet provider". Is it because they know the mnemonic phrase? Is it that they generate it so they know it?

No, it is because you are using whatever web wallet software they serve to you at the time you visit their website. You have absolutely no control over what software you are actually using (as in what the code is). So that software could be malicious, and there would be nothing you could do about it. For example, suppose blockchain.info has been legally obligated to confiscate your coins. They could simply just serve you and only you a modified version of their software which sends all of your private keys back to them in an unencrypted form and all transactions that that software makes just sends the coins back to blockchain.info. This does not even have to be blockchain.info being malicious; it could be a man-in-the-middle attacker who has hijacked your connection to blockchain.info and served you the bad software.


Send bitcoin with bitcoin core without syncing to network I want to use bitcoin-core just for sending bitcoin from my address to another destination address. i don't need the huge history information of blockchain. In fact, I want to run a light-weight bitcoin-core service in my local machine and just use its commands related to create, sign and send transaction. Is it possible without syncing to blockchain network and downloading blocks?

Thank you in advance

Reza Hedayati

A fully synced Bitcoin node is the only way to know without trust that the coins you think you own are really yours. Otherwise, someone can trick you into thinking you have money you don't. You can try to spend the counterfeit coins, but the network will reject your transaction.

If disk space is your primary concern you can run your node with pruning active, which deletes old blocks from disk but maintains a complete UTXO set, which is all you need for full validation.

If bandwidth or CPU is your primary concern, you can investigate the SPV and Neutrino models, which compromise privacy and security in varying degrees for convenience.

Finally, and this is not recommended, but you can trust someone to run a full node for you and provide you with the minimal amount of data you need to create a transaction which you can then sign and broadcast locally. This can be done (for example) by requesting transaction data from Blockstream's esplora API and you can see an example of such a construction in my (novelty-only-do-not-use-for-real) brainwallet sweeper application: https://github.com/pinheadmz/brainsweeper


How many transactions can a bank/person make per block I’m trying to determine if bitcoin is too expensive for a bank to use.

Assume that a bank would use bitcoin for something like confirming transactions between itself and another bank I’m asking how many transactions on a single block can a bank make?

I’d like to answer the question 1 Bitcoin Cost / Number of transactions = cost to bank / transaction

Any thoughtsb   Is this the correct way to think of the worth of bitcoin?

The cost of a Bitcoin transaction doesn't scale respective to the amount that is being sent, but according to the amount of data that the transaction occupies on the blockchain. The Bitcoin blockchain produces about one block every 10 minutes which can (depending on the transaction composition) carry about 2,000 – 4,000 transactions.


Storing my bitcoins on an offline computer I have a mac that I never use, would storing my bitcoins on a wallet on that laptop and then only connecting it to the internet when I am ready to transfer money be safe? Is there any reason not to do this? That way I don't have to worry as much about viruses infecting it and stealing my bit coins?

Also, what happens if I back up a computer, load it onto a new hard-drive, then open up that computer and run it's wallet, then open the original computer and run it's wallet.. now I have two duplicate wallets on two separate computers? Would I get an error from the P2P network or would I have duplicate coins (I'm assuming the second is obviously not the case)

I have a mac that I never use, would storing my bitcoins on a wallet on that laptop and then only connecting it to the internet when I am ready to transfer money be safe? Is there any reason not to do this?

Your laptop needs to catch up every time you want to make a transaction, which is not good.

The ideal solution would be Bitcoin Armory, which is designed for this type of thing:

How to sign a transaction using only an offline computer?

Find the mac version here - but note that it's in beta, hence why it's not on the main site.

  Would I get an error from the P2P network or would I have duplicate coins

The second time you spend the coins, other nodes will reject it.


Limits to the number of accounts? I wonder: is the built-in accounts facility scalable enough that you can assign each newly minted address to a different account?  Or am I going to run into hard limits, or a database that becomes too sluggish because accounts were meant to be few in number?

There most likely isn't any hard limit - you might only be limited by your computer's memory (and even then, that would require tons of addresses).


How to get balance by any address using rpc bitcoind? How to get balance of any address using rpc bitcoind?

I mean getting by address the list of his unspent outputs in view something like this: TxHash;Value;Noutput.

You would run the listunspent response through a loop and total up all the values from all the unspent outputs for that address.


How to find the wallet balance? I'm trying to find the balance of specific addresses in a wallet. I basically have the master key which I use to generate addresses but I wonder, is it possible to find the derived addresses that have any balance and how can I query it (the balance of the addresses, and thus the wallet)?

I know I can generate infinite derived(child) addresses from the master key so, am I supposed to keep generating addresses and check every single one to see if it has any balance? Are you supposed to store both the master key and the addresses that you generate to receive payments?

If you have the master private key for an HD wallet, then software can easily generate derivative addresses, and check the balance of those addresses against the UTXO set.

  am I supposed to keep generating addresses and check every single one to see if it has any balance?

Wallet software will have a set number of addresses it generates and checks for a balance upon wallet initialization (maybe 50? this will vary and is configurable in some software). The wallet will probably include some logic like "look 50 addresses past the last used address found". You can design this to fit your need, for example if you were a merchant accepting payments on a busy website, you might need a higher bound, in case 50 customers in a row generate a payment address but then don't complete checkout.

  Are you supposed to store both the master key and the addresses that you generate to receive payments?

The wallet software will do this for you, but ultimately you do not need to explicitly keep a list of every private key / public address derived from your master key in order to access your funds later. If you have the master private key saved you will be able to recreate all derived keys from it.


Lost bitcoin because of deleted receiving wallet id Is it possible to recover the bitcoin that was sent to a wallet that generated using payeer which I deleted on accident? The transaction also shows completed from the other wallet.

Not sure exactly what you deleted, but it looks like one of two things.

The wallet as listed in your software.
The file(s) associated with your wallet that your software uses.

If number 1, depending on the wallet, the files containing the private keys might still be on your hard drive. Look in the program folders and see what you find. Without knowing more, plus your wallet software, that's all I can give you.

If number 2, your only hope is if you have the private keys. Wallet files are just a list of private keys and portion of the blockchain. So if you don't have the private key, you have no bitcoin. If you backed up the private keys in some way, that's your answer. Create a new wallet and "sweep" the private keys into a new address.


How can a block be considered more difficult to solve/hash than another one? In this answer: https://bitcoin.stackexchange.com/a/760/28219

It is said:

  Because of all this work, when a Bitcoin client signs on to the
  network it can trust the block chain that was most difficult to
  produce (since this is evidently the one that was being worked on by
  the most miners).

There is nothing evident there :)

Can someone explain how can a block be more difficult to solve than another one? Does it have to do with the number of transactions it contains?

All blocks have a field for their 'difficulty'. This is a parameter that determines how many hashes have to be calculated (on average) before you find a block. Higher difficulty means the block will be harder to solve.

  How can a block be considered more difficult to solve/hash than another one?

Think of it like flipping coins, where the difficulty number is the number of Heads you have to flip in a row. So, With difficulty 8, you have to get 8 heads in a row, etc. Difficulty 9 is harder than a difficulty 8.

This difficulty number is used to increase/decrease the number of blocks solved on the network, according to very specific rules, in order to keep blocks solved at an average of 10 minutes. If the network is solving too many blocks, say a block every 9 minutes on average, then the network will increase the difficulty. Similarly, if the network is only solving blocks every 11 minutes at the current difficulty, then the difficulty is lowered. This re-adjustment process happens every two weeks in Bitcoin.

The tricky part is what can happen if a fork takes place at the same time as the difficulty adjustment. Let's say our blockchain looks like this:

                X_8
              /
-> X_8 -> X_8
              \
                X_8

(Where 8 is the difficulty of each block). Since the top fork and the bottom fork have different time fields in their block header, they result in a different difficulty re-adjustment calculation (difficulty re-adjustment is based on number of blocks in a given time, trying to keep it at a block per 10 minutes). Now the next blocks on either side of the chain, which have the newly calculated difficulties, at not given the same weight.

                X_8 -> X_9
              /
-> X_8 -> X_8
              \
                X_8 -> X_7

Since the difficulty re-adjustment in the top fork ended up with a higher difficulty, any block solved on that half of the chain (X_9) will override a block solved on the bottom side of the fork (X_7). However, if X_7 had been solved significantly before the X_9 block, then that would be the chain with the most work (8 + 7 on the bottom chain is better than just 8 on the top chain).

The network essentially looks for the chain of blocks with the highest sum of difficulties, i.e. the chain that took the most work to produce, and would be the hardest for an attacker to try to override. Nodes on the network choose this highest-difficulty-sum chain as their correct chain, and the great thing about this is that when everyone follows the simple rules, they arrive at consensus about the history of transactions.

  Does it have to do with the number of transactions it contains?

No.