At which stage is a transaction validated? Let's say Alice owns 12 BTC in her wallet, and she tries to send 5 BTC to Bob. First the transaction is broadcast to all nodes, then transaction is in the transaction pool. Then miners would choose Alice's transaction and add it to their block and find the nonce, and once they've found the nonce, they will broadcast the block with Alice's transaction. In that flow, at which stage is the transaction validated?

Whether while each node receives the transaction ?. Is it the stage , requires 51 % confirmation to validate the transaction?
Otherwise at the stage , once miner found the nonce, he has to broadcast the transaction , other miners will verify the correct combination of nonce.In this stage , does miners need to verify the nonce along with the all the transactions in the block??

@James C.'s answer is correct, but I'll add a bit to address your two questions specifically:

  Whether while each node receives the transaction ?. Is it the stage , requires 51 % confirmation to validate the transaction?

No, each node acts independently, and there is no way to measure what percentage of them have accepted a transaction as valid. Because of this, whether or not a transaction is valid has no bearing on its permanence or place in the blockchain record, it is simply a yes/no check on whether the transaction is valid according to the network's rules. Invalid transactions will of course be rejected by the nodes, and thus not relayed through the network.

Any valid transaction can then be included in a new block. Once that happens, the transaction is said to be 'confirmed', though it is prudent to wait for a few confirmations before considering a transaction to be finalized.

Notice the difference between 'validation' and 'confirmation'. It is possible for a valid transaction to never be confirmed in the blockchain (perhaps it has zero tx fees, or somehow is never relayed to a miner), but it is not possible for an invalid transaction to be confirmed.

  Otherwise at the stage , once miner found the nonce, he has to broadcast the transaction , other miners will verify the correct combination of nonce.In this stage , does miners need to verify the nonce along with the all the transactions in the block??

A miner will construct a block from valid transactions, and if a valid block is found, it will be relayed to the network. All other nodes and miners will check this block to ensure they have validated each of its parts. Similarly to transaction validation, invalid blocks will be rejected by the network's nodes.


Specifics on "Race Double Spending Attacks"? Hi guys I am doing some research on double spending in the bitcoin network several ideas have been confusing me:

In prevention of Race attacks, merchants are advised to "connect to a large random sample nodes in the network".

First of all, What do they mean by this? How is it done?

Secondly, how do attackers initiate the attack? All I know is they make 2 transactions of same reference, one to themselves the other to the merchant who recognizes only the latter and surrenders his goods.

In an article on prevention, it states "We assume that the attacker may connect to an arbitrary number of nodes in the network to broadcast any number of transactions claiming outputs to its possession."

What exactly does this mean?

Thank you guys, I know this question is very condensed but I appreciate any help.

EDIT: Does it mean that I can go out and send X amount of bitcoins to myself and immediately spend the same amount, X on a merchant to defraud him?

Isn't that just too easy?

You have already answered your question. The basic double spending attack in question is just that: The attacker initiates a Bitcoin transaction and claims a benefit from it. Then the attacker does the same thing again, potentially broadcasting the new, conflicting transaction to a larger number of nodes in the Bitcoin network, in an attempt to have the new transaction confirm instead of the first one. If that succeeds depends on which kind of miner, one having seen the initial or the later transaction first, manages to mine the next new block (with a few extra caveats, like that miner actually choosing to include said transaction in his newly mined block).

Computer scientists call this general phenomenon where the overall outcome from concurrent processes depends on what happens first a race condition. The race condition I just described can continue if nodes continue mining on different subchains where one contains the first transaction and the other subchain contains the other transaction from the double spending attack.

There are also more complicated forms of double spending attacks, but all of them have a race condition to some extent, and hence I would call all of them eligible for the description "Race Double Spend." You may also be interested in one, the Finney Attack, that makes the race condition almost disappear through premining, such that the attacker has an almost unbeatable head start if the recipient (e.g. the merchant) instantly accepts an unconfirmed transaction.


Where can I see the current size of the bitcoin blockchain? I am tying to understand the concept of the bitcoin blockchain, from what I understand everybody owns a full copy of the bitcoin blockchain, but is it possible to see the current size somewhere without having "checked it out/cloned it"?

And are there any backups being made? I know it's distributed and everyone owns a full copy - kinda like with a git repository - but is it also backed up on centralized servers?

Yes, you can use this website:

https://blockchain.info/charts/blocks-size


How to run multiple node in same machine? I have created an altcoin base on litecoin source code. I want to test it in multiple node to test peers of each node weather each node can connect to each other. So I try to run "mycoind" in multiple but it not work. Any way for me to run multiple node in same ubuntu machine?

Your problem here is nodes are trying to use the same port Accept connections from outside.

You have to change the default port or disable listening.

-port=<port>    Listen for connections on <port> (default: 8333 or testnet: 18333)

or

-listen Accept connections from outside (default: 1 if no -proxy or -connect/-noconnect)

If you want to add another peer just simply add "-addnode:127.0.0.1:" to mycoind command.


Why can't timestamps be a substitute for blockchain? I'm super fascinated by the entire concept of proof of work and how it allows for a trustless, decentralized system. Despite knowing that proof of work (or proof of stake) can be an inevitable necessity to having a cryptocurrency like Bitcoin, I'd like to fully understand where other methods fail.

The first problem Bitcoin addresses from my understanding is signatures with each transaction. To me, this completely makes sense, as it is completely necessary to be able to verify that the sender indeed was the creator of the transaction. But then the next problem is transaction order and validity to prevent double spending. I don't understand completely why a timestamp can't just be included for every broadcasted transaction, and the transaction could have the correct, universally agreed upon time, and each ledger gets sorted chronologically. Is this because it requires a centralized system to prevent people from forging timestamps? Or what am I missing? To me, it seems like if the transactions were broadcast publicly to the entire network, there wouldn't be conflicts in ledgers / double spending.

And how exactly does the main blockchain stay decentralized? Let's say I go offline and miss transaction broadcasts, and now I want an updated version of the main blockchain. I would have to rely/trust others for this main blockchain, which seemingly is centralized now in the way that all new users are pulling from this same copy of the blockchain. I don't quite see how that's different from the analogy with a community ledger with everyone just keeping their copy updated with that, or a main branch on a git repo which everyone continually pulls from. There is no single point of failure, but it seems to still be a community ledger in a sense.

I am completely well aware that the "solutions" I presented above have faults somewhere that I'm missing / scenarios in which these will fail which I haven't considered, and I'd like to understand exactly why a proof of work system is necessary in these scenarios. And, how it can stay decentralized and trustless despite having characteristics described in the above paragraph. This, I believe, will help me understand the true beauty of it.

But then the next problem is transaction order and validity to prevent double spending. I don't understand completely why a timestamp can't just be included for every broadcasted transaction, and the transaction could have the correct, universally agreed upon time, and each ledger gets sorted chronologically. Is this because it requires a centralized system to prevent people from forging timestamps? Or what am I missing? To me, it seems like if the transactions were broadcast publicly to the entire network, there wouldn't be conflicts in ledgers / double spending.

You need to remember that communication networks aren't perfect. There are latencies, and there are nodes connecting and disconnecting. The system needs to be robust to these dynamics.

You also need to remember that the problem Bitcoin set out to solve is how can a merchant know that a payment to him is final and will not be reverted.

Suppose a double spender pays a merchant, with a tx timestamped at 13:05. The merchant see the tx and provides the goods. The attacker then broadcasts a conflicting transaction timestamped at 13:04.

A node receiving this new transaction has no way of knowing whether the timestamp on this tx was forged, or if it was indeed broadcast at the specified time, and he has simply missed it so far. Since the rules say earlier txs take precedence, the payment to the merchant will be reverted.

And that's when the node was actually connected to the network at the time these transactions were broadcast. What if it's a new node, or it had downtime at that point? How could he possibly ever know which of these transactions actually appeared earlier on the network?

That's exactly what proof of work and the blockchain are solving - they are a permanent record that everyone can agree on, which is hard to forge because it includes proofs that actual computational work went into verifying it.

  And how exactly does the main blockchain stay decentralized? Let's say I go offline and miss transaction broadcasts, and now I want an updated version of the main blockchain. I would have to rely/trust others for this main blockchain, which seemingly is centralized now in the way that all new users are pulling from this same copy of the blockchain. I don't quite see how that's different from the analogy with a community ledger with everyone just keeping their copy updated with that, or a main branch on a git repo which everyone continually pulls from. There is no single point of failure, but it seems to still be a community ledger in a sense.

The blockchain actually contains proofs. I don't need to trust any node - if I get conflicting blockchains from different nodes, I know which one is the correct one because it has proof of more computational work. This allows all nodes, everywhere, no matter when they connected, to agree on the same shared ledger.

And that's all that matters - agreement. As long as everyone agrees on which order of transaction is correct - in particular, the person who gave goods in exchange for bitcoins and the people he will later want to send these bitcoins to - the payment network works.


Why did repeated "R" values occur in Bitcoin transactions before? Please explain why earlier the repeated values of "R" occurred in Bitcoin transactions.

For example, this transaction has a repetition of the value "R":
https://www.blockchain.com/btc/tx/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83

If you look at RawTX:
https://btc.com/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83.rawhex

repeat value "R":

R = cabc3692f1f7ba75a8572dc5d270b35bcc00650534f6e5ecd6338e55355454d5

What was the reason for this? Explain the reason for this error?

The R value is the result of EC point multiplication between the k value (known as the nonce) and the secp256k1 curve's generator point. It is effectively the public key for k. The only way that an R value can repeat is if k is also the same. Given that k is a 256 bit number and is supposed to be chosen completely randomly, k should not repeat unless the random number generator is broken.

Considering that k is generated at signing time and should be random, we can conclude that whoever chose k for those transactions has a faulty random number generator which is either outputting a fixed value or a small value which increases the probability of k being repeated. There is no good reason for this to happen, so this error comes from either a faulty RNG or a completely misunderstanding of how ECDSA works.


Detecting dishonest merged-mining pool How would one go about detecting whether a mining pool is being dishonest by performing merged-mining without sharing the Namecoin income with its miners?

We assume that:

The pool is operating normally, albeit pays out only Bitcoin rewards
It merge-mines while claiming not doing such a thing

How could we find out the pool is in fact merge-mining and what are the tactics the pool can use to make our investigation harder?

The only way to know for sure would be if you mined for the pool and you mined a Namecoin block for them. You would find the particular header you had submitted as a share used as a solved, merge-mined Namecoin block.


Is it legal to buy concurrency in USA I would like to seek for your help since I would like to have confident answers on the following questions:
(please include links for official websites)

Is it legal to buy & hold currencies (such as ripple, bitcoin,etc..) as a kind of investment in the USA?
When do you have to tax after it?
Do you have to report is on your tax form even before you sell it or only after you sold the currencies?

So far this is what I found:
https://www.irs.gov/pub/irs-drop/n-14-21.pdf

Yes.  It is legal to buy cryptocurrencies in the USA and they are taxed like property by the IRS.

See https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory#North_America

From the WIKI:

  The U.S. Treasury classified bitcoin as a convertible decentralized
  virtual currency in 2013.[26] The Commodity Futures Trading
  Commission, CFTC, classified bitcoin as a commodity in September 2015.
  Per IRS, bitcoin is taxed as a property.[27]

  In September 2016, a federal judge ruled that "Bitcoins are funds
  within the plain meaning of that term".[28]

  [26] "Statement of Jennifer Shasky Calvery, Director Financial Crimes
  Enforcement Network United States Department of the Treasury Before
  the United States Senate Committee on Banking, Housing, and Urban
  Affairs Subcommittee on National Security and International Trade and
  Finance Subcommittee on Economic Policy". fincen.gov. Financial Crimes
  Enforcement Network. 19 November 2013. Retrieved 1 June 2014.

  [27] "IRS Virtual Currency Guidance : Virtual Currency Is Treated as
  Property for U.S. Federal Tax Purposes; General Rules for Property
  Transactions Apply". www.irs.gov. Retrieved 2017-04-22.

  [28]
  https://www.reuters.com/article/us-jpmorgan-cyber-bitcoin-idUSKCN11P2DE


How accounts, wallets and addresses are related I have downloaded litecoin code (version of 14 september,2014) and built it. so right now I have a wallet. i have account which's name is just "". then i connected my miner to my node. It solved the block and now I have a balance. ./litecoin-cli getbalance "" returns 150LTC , but as I can see, there're 3 addresses which belong to this account (""); why all of these 3 addresses have balance 0.000? how is it possible that account has a balance and not the addresses? Even if i type ./litecoin-cli getinfo it tells me that my balance is 0.0000 , but if i type ./litecoin-cli getbalance "" why does it return 150?

When you mine a block and get the block reward (50 LTC in your case), the coins are not spendable immediately. There is a maturity period of 100 blocks before you can spend them. I believe this is why they don't show up.


Transaction Hash Chain Signature: What Is Getting Signed? In Satoshi Nakamoto's diagram:

I understand this diagram is dated--but please bear with me. I think I have missed a critical point of the diagram:

Question:
Let's assume that the three transactions depicted are #1, #2, and #3 from left to right.

Is the Signature for Transaction #2 computed using Owner 1's Private Key and the Transaction data for Transaction #1 or is it computed using Owner 1's Private Key and the Transaction data for Transaction #2?

Thank you.

Question: Let's assume that the three transactions depicted are #1, #2, and #3 from left to right.
Is the Signature for Transaction #2 computed using Owner 1's Private Key and the Transaction data for Transaction #1 or is it computed using Owner 1's Private Key and the Transaction data for Transaction #2?

The Signature for Transaction #2 is computed using Owner 1's Private Key and the Transaction data for Transaction #2.


How exactly is bitcoin priced How does bitcoin and other cryptocurrencies price the value of the currency? How exactly does this work. Do buyers just set a max price at which they want to buy and sellers a min price at which they want to sell and they are matched? Or is there something more complicated at work? I'm really interested in understanding how this works. Any details would be much appreciated

That's exactly right. People who want to sell bitcoins typically set a minimum price and people who want to buy bitcoins typically set a maximum price. When they meet, a sale takes place.


Is 'hawala' and Bitcoin similar? Hawala is an old indian/middle east , money transaction system , based on mutual trust, and uses an encryption system based on spoken keycodes.How is it similar to bitcoin transaction system?

The major difference is, while Hawala means trust, Bitcoin does not depend on trust. Everything is made of cryptographical signatures, making it 100%** safe, while Hawala cannot / may not be trusted.

** Two exceptions: 1) Majority of hashrate is attacking the network. See this 2) The theoretically possible, but practically impossible hash collisions. It doesn't happens, while the theoretical safety isn't 100%, rather 99.999999999...%


How do I restore a Ripple wallet backup? In the Ripple client (as of 0.2.48-2) there is a way to backup a wallet to a text file. How can we use this file to restore a wallet (for example, to a new browser)?

I am aware how to regain access to my wallet having the secret key, yet, I would also like to reimport the contacts that were stored in my wallet.

This was already asked here.

  Following these instructions, after clicking on Create a new wallet,
  you will have the option of using a custom secret key.


`lnd` on Raspberry pi zeros? Did somebody try to run the bitcoind full node on the Raspberry pi 3 and one or more lnd nodes on one or more Raspberry pi zeros?

My goal is to support multiple LN clients without having to run a full node for each client. Raspberry pi zeros are cheap, storage and bandwidth are not.

One node to rule them all and in the darkness bind them

Run a Raspiblitz (EUR120)
https://github.com/rootzoll/raspiblitz

Then run slave devices on ESP32 (EUR5)
https://github.com/musdom/sploony
https://github.com/arcbtc/1.21

121 would need to be ported with macroons


What would happend if a country were backed by its own cryptocurrency? What would happen if instead of depending on dollars or gold, a country were backed by its own cryptocurrency, would this benefit its citizens and the country itself? How?

I've read this answer but it's mostly about bitcoin, and not about a country's coin.
Sorry if the question is out of place.
Thanks!

As this has not happend yet, the only thing we can do is "speculate" about the answer.
However, this may change in the near future, Estland is currently creating it's own cryptocurrency.
One of the key advantages for citizens of the country would be that they would have a currency which does NOT devalue / inflate like something as the dollar / Euro, since you can't just suddenly make another billion of them.
However this at the same time is also probably the reason why it will never work.
Countries can't for example "press" more money.
But, the cryptocurrency could also make life easier in the following ways,

Imagine for example if you as en r-resident could charge Estonian customers in estcoins,
pay your corporate taxes and public services in estcoins,
and estcoins is accepted as legal tender in the same way as euros in Estonia. If this actually happens, then there is no limit on how deeply integrated cryptocurrencies could become in everyday life.

Also, it would, if the coin is bitcoin based ( open ledger blockchain.) protect the citizens from their own government.
Meaning they can for example see and verify exactly where their money is going, due to the blockchain.


What increases a node's banscore? What increases a node's banscore? What factors contribute to the banscore? Does a node sending bad transactions increase its banscore? Does its using unnecessarily too much bandwidth also increase its banscore?

There are many facts that can increase a node's banscore. A node's banscore is updated in the Misbehaving function from main.cpp. Some of the reasons that trigger such update are:

Sending invalid blocks.
Sending duplicate version messages.
Not sending first a version message (before other communication).
Sending addr messages with more than 1000 addresses.
Sending inv messages with more than 50000 elements.
Sending header messages with more than 2000 elements.
Sending too large bloom filters.
...

Regarding transactions, it seems that they also may increase the banscore:

  // Punish peer that gave us an invalid orphan tx


In a multisig wallet setup what needs to be backed up and why? In a multisig wallet setup what needs to be backed up and why?

Ben Kaufman answered this on Twitter.
The main caveat in a multisig wallet is that, while you need only a threshold of devices (ie. 2 of 3, 3 of 5, etc.) to sign a transaction, losing access to even a single device could potentially prevent you from being able to spend the funds - if you don't back up properly!
The reason is that (usually) in order to make a Bitcoin transaction, it is not enough to be able to sign it, but you also need to provide the "terms for spending", that is, the Script (code) that is used to lock the coins.
That's because the full script is usually not stored directly on the blockchain, but only as a hash (a unique identifier of it). In a single key wallet, this is trivial.
The script is composed of the public key of your wallet and a few standard commands - and satisfying it requires the signature for that key, so both the script and signature can be constructed by having access to that one private key.Then on spending, you need to provide both the original script code which matches that hash, and satisfy any condition that the script may include.
With a multisig, this is not the case. The script for a multisig contains the list of public keys of all possible cosigners - which means it can be constructed only by knowing the public keys of ALL devices in the multisig, not just of the devices you are signing with.
To demonstrate, let's assume a 2 of 3 multisig. When you want to get an address of your multisig, your wallet software is taking the public keys of all 3 cosigners, lists them in a standard way inside a script, hashes it, then with this hash constructs the address.
When receiving bitcoin to that address, there is a "commitment" on the blockchain for all 3 public keys, out of which 2 signatures are needed. But the public keys themselves are not listed yet on the blockchain - you must provide them too when spending from the address.
Now assuming you have lost access to one private key (a device and its mnemonic backup), you won't be able to tell its public key anymore - so you won't be able to reconstruct the script of the address. So even though you have enough signatures, you won't be able to access funds.
The solution - which is the extra step of a multisig backup - is to also keep a backup of the list of public keys (xpubs) of all cosigners, from which you will be able to recreate the script.
Since this list of public keys does not contain signing (private) keys, there is no risk of losing funds even if an attacker manages to access it, but this would be a privacy concern since the attacker will then be able to see the balance on the multisig wallet.
That's why it is not recommended to leave this file on some cloud backup or some other insecure option.
It's recommended that you keep it with each one of the cosigners/ seed backups so that you can recover regardless of the combination of signers you eventually use.
Besides the list of public keys, it is also necessary to know the script type used (whatever native SegWit, nested SegWit, or legacy), and the threshold chosen in order to construct the multisig script. These are possible to know by guessing (brute force), but better keep it too.
The last piece which you should include is the derivation paths used for each device. Each derivation path tells your wallet how to turn each master public key, into a different individual "disposable" public key used to generate every new address.
This data of derivation paths is standardized so that all wallets should use the same derivation path by default, but it is best to keep that around too especially if you use a unique one for some reason.
This might sound like a lot of components, but to simplify usage, there’s a standard for storing and recovering such information, which is called Output Descriptors.
Just as an example of what the final backup might look like, here are a few pics of a PDF backup generated from Specter Wallet.

This contains the individual devices keys list, as well as everything in an output descriptor format (and a bit of extra data like wallet name etc.)
You could save this by simply printing the PDF, storing it on an SD card, or just keep it encrypted on a cloud backup. What you need to remember is:

You need this information to recover the wallet.
Anyone with access to this information can see your wallet history.

So to simply sum it up, the additional piece you should backup when using a multisig wallet is the output descriptor - a list of the public keys of the cosigners with some data on the wallet.
This information is possible to derive only with access to all devices in your multisig and is necessary to spend from it.
So to remove the single point of failure of losing access to one cosigner, you should keep this backup along with each of your devices.


Can non mining full nodes prevent 51% attack? Does it actually strengthen the network? I am confused of its real purpose From what I understand, miners secure the bitcoin network by making it very-very expensive to do a 51% attack or double spend bitcoins through the sheer amount of hash power needed to overwhelm the network.

That implies, if the hash power happens to be very low (for whatever reason), an entity could theoretically mount this attack and thus reverse transactions or double spend the coins.

So what is the role of non-mining full nodes then? Does not seems to serve any real purpose to me?

Non-mining full nodes cannot prevent a 51% attack, but they are essential in preventing other attacks.

In particular, full nodes verify that the chain produced by miners is valid. This means that  no coins are transferred without proper authorization from their owner, that no new coins are being created out of thin air (except for those permitted by the inflation schedule), and a few other things.

Full nodes are what keeps miners honest. To anyone who verifies incoming transactions themselves using a full node ("economically relevant full node"), it guarantees that the chain is valid. Miners have no way to cheat those (apart from a 51% attack, see further), and as a result, they have no incentive to produce blocks that violate the rules, as such blocks will be dropped on the floor and ignored by full nodes. To anyone not running a node themselves, the knowledge that a sufficient number of other independent parties are running full nodes helps, because hopefully those parties are important enough that miners wouldn't want to waste their money creating an invalid block they would detect.

Bitcoin's security is based on auditability, not trust. You know the chain, in its entirety, is valid, because you're able to independently verify that it is.

Unfortunately, there is no way to verify which of two conflicting (but otherwise valid) transactions is the "real" one without a central clearinghouse that blesses one of the two. This is called the double spending problem, and it is the reason why we need miners: a decentralized clearinghouse that anyone with the right hardware, even anonymously, can join. Producing blocks costs money for them, and they're only paid if the network of full nodes accept their blocks. This is why they're incentivized (but not forced) to produce blocks that satisfy the rules, and build on top of each other's blocks.

But it is important to see that the 51% attack is the exception here. For almost every rule in Bitcoin, full nodes verify everything, and there is no way they can be fooled. The only thing that cannot be verified independently is double spends, which leads to a 51% attack if exploited (but the theory is that this would be expensive for miners so not economical; furthermore, if miners aren't doing their job well, others are incentivized to become a miner themselves).


Currency exchange process I'm trying to understand all the logical steps that occur when a buy or sell order is submitted to an exchange such as Coinbase.

From what I understand currently, this is the general process. Am I on the right track here?

Where I think I'm wrong is step 3 and 7. I'm not sure if the tokens actually go to Coinbase for holding while the sale is "pending" or not.

The exchange needs to have custody of the assets (tokens for a sell, money for a buy) before an order can be placed.  That's the only way they can guarantee that the order will execute as soon as it is matched, and that both parties will receive their assets, without the ability to back out.

So the correct order of your steps is:

  3, 4, 1, 2, 5, 9, 6, 7, 8, 10.

Of course, variations are possible: 9 could happen earlier, for instance.  The buy order could be placed before the sell.  Or the buyer could wait to withdraw the token they bought.

This doesn't account for the possibility of things like margin orders, where the exchange might allow someone to buy using money that's borrowed instead of deposited.


Who benefits from mining? After reading many articles, I didn't find an answer to the following.

  "Miners use special software to solve math problems"

Okay, but for whom? Are there organizations or people that need those math problems to be solved?

Its not a math problem. Its just search for partial collision in function called sha256.

Sha256 is a famous type of puzzle.

During the writing of this post, a block  397108 was mined.

The solution looks like this:
00000000000000000497b28e9c38673ef8fd2fed317d6eca8a579350b1cba0a6

Notice the zeroes on the beginning. The more zeroes the harder is to find a solution.

The only reason is to waste power to prevent creation of funds from thin air (prevent print too much money) and to confirm payments.


How do I fully uninstall the Bitcoin Wallet app for Android? My phone is rooted and I'm not going to use the Bitcoin Wallet app anymore since I'll be switching to another one. My problem is, I can't seem to find where the downloaded blockchains are stored. If I'm not mistaken it's supposedly gigabytes big but I can't find it anywhere on my phone. I'm pretty sure the first time I opened up the app, it appeared to be downloading them.

Can someone tell me what directories I should delete to ensure that the app is fully removed from my phone. (I just don't want rogue data lying around and taking up unnecessary space)

The size of the blockchain download by BW has significantly reduced recently, and is only headers at best so you're only looking for a 20-40Mb file not gigabytes.

You should be able to locate the private keys here:

/data/data/de.schildbach.wallet/files

If you need assistance with accessing your rooted phone (you probably don't) I wrote an article detailing Bitcoin recovery operations on Android that may provide useful supporting information.


Ubuntu. (blockchain of version 0.9.3 compatible with 0.10.1?) I have version 0.9.3 of bitcoind on my Ubuntu server and I want to upgrade to 0.10.1,
I have nothing in my wallet.
Does the blockchain 0.9.3 compatible with 0.10.1?
Do I have anything to keep from version 0.9.3 ?

In the official release announcement here:
https://bitcointalk.org/index.php?topic=1039713.msg11211433#msg11211433

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software*

So upgrading works fine, but if you later decide to downgrade the block and database files won't be compatible.


How does a non-segwit full-node validate a SegWit input From segwit part of reading bitcoinbook, there is an example for upgrading P2PKH to P2WPKH:

  Alice created a transaction to pay Bob for a cup of coffee. That
  transaction created a P2PKH output with a value of 0.015 BTC that was
  spendable by Bob. The output’s script looks like this:
  Example P2PKH output script

DUP HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 EQUALVERIFY CHECKSIG

  With Segregated Witness, Alice would create a
  Pay-to-Witness-Public-Key-Hash (P2WPKH) script, which looks like this:
  Example P2WPKH output script

0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

Inputs for them are like below:
For traditional P2PKH:

[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “<Bob’s scriptSig>”,
]
[...]

For P2WPKH:

[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “”,
]
[...]
“witness”: “<Bob’s witness data>”
[...]

So what if a full-node has not upgraded to new version with support to segwit? It seems that client without support for segwit will always validate the second input as true. Because in the book, it is said:

  As you can see, a Segregated Witness output’s locking script is much
  simpler than a traditional output. It consists of two values that are
  pushed on to the script evaluation stack. To an old (nonsegwit-aware)
  bitcoin client, the two pushes would look like an output that anyone
  can spend and does not require a signature (or rather, can be spent
  with an empty signature).

Question 1:
0 and ab68025513c3dbd2f7b92a94e0581f5d50f654e7 in stack-based bitcoin script does not return true.
Why the the "two pushes in segwit output looks like anyone can spend and does not require a signature" to old client?

Question 2:
What is the <Bob's witness data>? It looks like that <Bob's witness data> is different from <Bob's scriptSig>. Can anyone provides an example?

0 and ab68025513c3dbd2f7b92a94e0581f5d50f654e7 in stack-based bitcoin
  script does not return true

They do return true. Here is some pseudocode:

push ( 0 );
push ( ab68025513c3dbd2f7b92a94e0581f5d50f654e7 )
return ( pop ( ) != 0 ); // evaluates to true


MtGox withdrawal transaction not in blockchain I just withdrew some BTC from Mt Gox to address 1Mvk4YAtKZAP43wEhZ6ZQrTzLZwZzPxtTJ, transaction id 3dfa979af56ff061efbceed0dd7c9dc9fd8c774249544018f6bbf646323ff03b, but didn't receive the coins and the transaction isn't in the chain.  Should I be worried?

Unfortunately Mt.gox has tendency to delay BTC withdrawals from time to time. Happened to me couple of days ago too. I tried to withdraw 1.8 BTC to another address but the transaction didn't show up in the block chain. Eventually it did, something like 12 hours later. I heard other people have waited for days for their withdrawal to complete.

I recommend to open a ticket just in case, but realize that this is not uncommon.
Hope this helps ;)


Get available exchange rates of Ripple's built-in exchange I'm not hundred percent sure I got the whole principle of Ripple right. But as far as I could understand it is possible to deposit a currency into my ripple account/wallet via a gateway (e.g. USD via snapswap.com) and then send that currency to another wallet/ripple account and get it exchanged automatically.

For example I want to deposit 1 USD via snapswap.com into wallet1 and then send 1 USD worth of EUR to wallet2. This way, the owner of wallet2 receives my payment in EUR.

My first question would be:

Did I get this right, that it is possible to exchange a currency within the ripple network? Or is it that you have to convert your currency before you deposit into your wallet? In my example convert USD to EUR then deposit into wallet1 and send EUR to wallet2.
Is there a way I can see the exchange rates the ripple network can offer my for any currency pair? e.g USD / EUR.
I want to know if there is a way to get the exchange rate at which my USD will be converted to EUR, before I send the USD / EUR to wallet2. Or, do I have to send my money haphazardly?

Did I get this right, that it is possible to exchange a currency within the ripple network? Or is it that you have to convert your currency before you deposit into your wallet? In my example convert USD to EUR then deposit into wallet1 and send EUR to wallet2.

Yes, you got it right. Ripple contains order books for any pair of assets.

  Is there a way I can see the exchange rates the ripple network can offer my for any currency pair? e.g USD / EUR.

The best way is to attempt the conversion in the client. If you try to view the exchange rates, you will see only a small subset of the available liquidity.

  I want to know if there is a way to get the exchange rate at which my USD will be converted to EUR, before I send the USD / EUR to wallet2. Or, do I have to send my money haphazardly?

You can estimate the exchange rate by viewing order books in the client or on Ripple charts. But there are a number of reasons why the rate you actually get may not be the rate you see. For example, the best rate may be by exchanging USD for XRP and then buying the EUR with the XRP. The conversion function uses pathfinding.

Also, note that there's really no such thing as USD or EUR on the Ripple network. There are assets denominated in USD or EUR, and there may be more than one of each. The actual exchange rate you get may depend on the precise asset combination you are trying to exchange, not just which currencies it's denominated in.

You would expect an asset issued by a major exchange to be available for very close to face value and you might expect to get near face value for it. But there can be small variations. Providing assets widely valued near face value is essentially the purpose of a gateway.


What is the best way to earn money mining Bitcoin? Simply stated- what is the most cost-efficient way to earn money from mining Bitcoin?  I've been a HODL'er since '14 but I recently wanted to deep-dive into mining for fun and was surprised to find how easy it was to do with a Raspberry Pi, slushpool account and a little bit of help from StackExchange:Bitcoin.  My question now is- do I build a Raspberry Pi "bucketwheel" equipped with USB-miner sticks like the crate displayed below, purchase an Antminer S9 or go to the cloud?  I'd appreciate any guidance or considerations for generating >= $100 month- again this is just for fun in experiment; I'm not looking to become the Hunt Brothers of Bitcoin ;)

If you mine with your RaspPi or your PC, you'll lose money because of electricity fees. The best way to mine is buying a miner (S9 is the best currently), but if you don't want to pay $1500, or don't want a noisy machine at your home, choose cloud mining. It's a bit risky, too.


what is type of wallet with 18 words seed? 1) I have 18 words seed

  spray inject... (18 worlds total)

2) And i have some password/secret key or private key

  GVzPYhu....... (35 letters total)

What type of wallet and what crypto currency can there be access to?
I have already tried Electrum. Its dont work.
I'm ready to reward someone who will help.

18-word phrase

I believe Coinomi was a wallet which would accept an 18-word seed phrase. There will be many others.

Coinomi lets you choose the length of your seed-phrase from a list of valid lengths: 3 6 9 12 15 18 21 24

35 random letters

Private keys are usually longer

Addresses can be 35 letters long but usually start with a digit or with bc1

See https://en.bitcoin.it/wiki/List_of_address_prefixes

Perhaps this is a passphrase for the seed-phrase - the BIP39 specification allows for an optional passphrase. Some wallets have an "option" button which may allow you to enter a BIP39 passphrase - though they may call it a "seed extension" or something else.


Where can one download Bitcoin Days Destroyed data? Alternately where to get data to calculate BDD? I'm trying to find a source of downloadable (preferably csv) data for Bitcoin Days Destroyed. Alternately I can calculate it myself provided I can find the constituent data.

In particular, I want to calculate dormancy which is total number of days destroyed  divided by volume. I know the total number of days destroyed is the value of the transaction multiplied by the number of days since that BTC was last moved.

Where can I find either data that has already been calculated for dormancy, or data on days destroyed, or barring either of those, the number of days since the last transaction for each Bitcoin?

For Bitcoin Days Destroyed data you can for example go there https://blockchair.com/bitcoin/charts/coindays-destroyed?interval=3m you can download the data they used in .csv

https://blockchair.com/bitcoin/ does a pretty good job at providing useful data, charts about the bitcoin blockchain

If you want to compute and made your own calculation yourself the best way would be to download the full blockchain 250giga+ with bitcoin core https://github.com/bitcoin/bitcoin and use a tool like Abe https://github.com/bitcoin-abe/bitcoin-abe to configure how the data are treated


How is the ledger stored on every node? I read different sourcing claiming the size of the blockchain for bitcoin.

Some says it's 8GB, some a 100GB and some 800GB.

Now I'm wondering do all the miners computers (nodes) have to store it all ? In case it's a TB it seems like a lot. Even though it's not it's still growing everyday, so is the blockchain really entierely stored on each nodes ?

Note : I used to mine a few years back I don't remember having my storage taken up by the blockchain.

Yes. The blockchain is stored completely on a full node (unless running in pruned mode) , there are mechanisms to prune and only keep relevant data, however pruning also requires you first get the complete blockchain. The size is approx 120 GB as of now. The blockchain is growing every day (rather every 10 mins).

Miners most probably have custom solutions to compute next block , so each pool node may or may not require the full chain.


Can a Miner or Mining pool have exclusive access to a transaction and its fees? Edit: This is a dumb question.  I was new to Bitcoin when I asked it.  Feel free to ignore or delete this Q:

Is it possible for a miner or mining pool to receive and not retransmit to peers information about a pending transaction?

Here is the scenario:

Several "normal" transactions are transmitted P2P with a transaction fee ranging from zero to 0.20 BTC.  One client wants to have priority processing with a miner either because they have a special business agreement, are a frequent user, or pays a fee.

Likewise the miner wants to have "first dibs" on high value transactions + fees, sometimes at the exclusion of other miners who aren't part of that "fee collective".

Question:

Is it possible for a miner to get "first dibs" access to a transaction, before the rest of the network sees the pending transaction?  How would this work, and can the current codebase support this?

A non-standard client could choose to send his transactions only to a specific miner. One example might be for a client to negotiate a "monthly package" (off the blockchain), and then send all his tx directly to the pool, without any specific tx fees.

There is nothing in the protocol that prohibits or enables it - it is a possible extension that is outside of the protocol. To my knowledge, no such schemes have been reported in the real world.


How do you generate a Bitcoin wallet by hand? I am interested in the exact process for generating the various components of a Bitcoin wallet by hand. Specifically, the components I'm interested in are:

Private Key
Public Key
Public Key Hash
Address

The kinds of tools I have in mind for doing the necessary calculations to generate each by hand is:

Pencil & Paper
Graphing Calculator
Any Other Non-electronic Mathematical Tool
Your Answer

If the process is not too tedious, I might try and give it go.

"Mining Bitcoin with pencil and paper: 0.67 hashes per day" suggests that doing SHA256 hashes by hand requires on the order of 36 hours of work.
I've done some work on "Verifying Bech32 Checksums with Pen and Paper", though I have not timed myself.  That work is slowly being folded into my work on Shamir Secret Sharing (over the Bech32 alphabet) using paper computers in my SSS32 project to design a new master-secret format.
I have never tried to do any elliptic curve operations by hand and I have always assumed that it doing so many modular arithmetic operations over such large numbers is just too tedious and error prone to do by hand.
If you are willing to use a computer to pre-generate a list of nonces (and SHA256 midstates for your nonce/public key for BIP340), it might be plausible that you could compute an ECDSA or BIP340 signature, as the remaining steps only require a few modular arithmetic operations.  While such a list of nonces is independent of your private key and your transaction, if that data were leaked it would compromise your private key from your signature, so even pre-computing that data may not be secure enough for whatever your purpose is.


Why do some outputs have a zero value and no address? What does it mean when an output has a value of zero and no address?  I'm looking at some fairly recent transactions, and I don't understand what this means.  Here's an example: https://blockchain.info/block-height/348120?format=json.

You can find the transactions quickly if you search that page for "value":0.

The outputs have no address because they are data-carrying outputs.

  {
     "spent":false,
     "tx_index":80899271,
     "type":0,
     "value":0,
     "n":3,
     "script":"6a144153435249424553504f4f4c5245474953544552"
  }

The script argument is the serialized equivalent of

OP_RETURN 4153435249424553504f4f4c5245474953544552

(The hex decodes to "ASCRIBESPOOLREGISTER")

OP_RETURN means that all attempts to spend this output will fail. This can't be spent, so there's no point in putting money in it - it would just be lost.


i lost my password and 12 word can i recover my password? I am new user  i crate my bitcoin wallet on zebpay   then my friend tell me  to creat bitcoin wallet on blockchain.info   as he suggest me i creat new bitcoine wallet  and send  40000 INR in new wallet after a week i try to open my wallet but  i forgot my password  when i try to recover it  system says to 12 word  but i have no knowledge about 12 word   now how i recover my money  please anybody help me

The only option left is to contact the support: https://blockchain.zendesk.com/


Signing transactions with un/compressed key Good day.

I've created 2 addresses from the same private key.
One address is of course compressed, while the other isn't.

compressed_public_key = "025d9a1a0a5dab7e3e4a84c30a42ddc0d71b2da0fa1f3b99fbda9fc03eb8c75cd5"
corresponding_address = "mfjRUvWr9QZadpiRnbRfHS4UDSxdR9FE75"

uncompressed_public_key =  "045d9a1a0a5dab7e3e4a84c30a42ddc0d71b2da0fa1f3b99fbda9fc03eb8c75cd535a0b893f20338d37d20eebe2941859dfe53b175f0bb24a27bc77741f0bb8cac"
uncompressed_address = "mi4kMd3HcLUGJSouNdJZ87eUBbi7cNE6C3"

I've also send some coins to each address.

utxo_to_compressed = "963baf6eb615a09afcb05ebcdbd3db05a163994dd2035002477c753ba3281eff"
utxo_to_uncompressed = "08a1286bb379f6eb5151828505b934c1b917201592bb76bd252a53b7a3009b17"

Using bitcore I've created the private_key to sign the transactions and the utxos as follow:

privateKey = new bitcore.PrivateKey(BN, "testnet")

scriptSig =  "76a914" + hashedPubKey + "88ac";

And the hashed public keys are:
1bf398bb044e55f1971e384cc1e6d861dca3adb9 for the uncompressed
025bafbac8a8a1fcbae04f9a6aa8b6f968c9d145 for the compressed

utxo_compressed = new bitcore.Transaction.UnspentOutput({
    "txId": "08a1286bb379f6eb5151828505b934c1b917201592bb76bd252a53b7a3009b17",
    "outputIndex": 0,
  "address": "mi4kMd3HcLUGJSouNdJZ87eUBbi7cNE6C3",
    "script": scriptSig,
    "satoshis": 5000000000
});

utxo_uncompressed = new bitcore.Transaction.UnspentOutput({
    "txId": "963baf6eb615a09afcb05ebcdbd3db05a163994dd2035002477c753ba3281eff",
    "outputIndex": 0,
  "address": "mfjRUvWr9QZadpiRnbRfHS4UDSxdR9FE75",
    "script": scriptSig,
    "satoshis": 5000000000
});

Signing the compressed utxo isn't a problem.  But once I'm trying to sign the uncompressed transaction I receive an error message.

compressedTx = new bitcore.Transaction();
uncompressedTx = new bitcore.Transaction();
compressedTx.from(utxo).to(some output).sign(privateKey); <-This one works fine
uncompressedTx.from(utxo).to(some output).sign(privateKey); <-This one fails
//Some inputs have not been fully signed Use//

In the past, I've sent and redeemed transactions from uncompressed public key (I did it manually, using a simple python code). I can't seem to find any reason why the inputs weren't signed.

I'll highly appreciate any help you might have to offer

compressed pubkey and uncompressed one have different hashes. so, your code should be something like:

scriptSig1 = "76a914" + hashedPubKey_1 + "88ac";
scriptSig2 = "76a914" + hashedPubKey_2 + "88ac";


What are the advantages and disadvantages of pooled mining? Is it better to mine solo? Is pooled mining what is recommended now? I've heard you get about the same back either way, but I am confused and would like some help.

Disadvantages of pooled mining:

Smaller expected earnings - pools usually charge a fee and sometimes use a reward system (like Pay Per Share) that can give you a lower payout.
Having to rely on third party system to earn your money - websites go down, and when they do, your miners can be idling.
Trust - you have to trust the pool owner not to swindle money from you, either by creating fake miners in the pool that do no work but still receive rewards or otherwise. Similarly, the pool owner can have an agenda of their own that they wish to further (for example, Eligius pool owner used their miners to attack an alt-chain, as well as putting prayers in the coinbase transactions).
Giving power to the pool owner - some important decisions regarding Bitcoin future are made by people voting with their blocks. Some time ago the Bitcoin community had to chose between two BIPs that fulfilled the same role. The voting was done by the coinbase transactions containing a vote for either one of the BIPs. By giving their computing powers to the pools, the miners essentially gave their votes to pool owners to vote as they chose.

Advantages of pooled mining:

More predictable payouts - pools usually pay you on a more regular schedule - be it once you reach a certain threshold, daily or the like. Solo mining only pays you when you find a block, which can take a few days, years, or never.
Extra features - Pools usually let you quickly check the status of your miners from anywhere, notify you of payouts and the like, which would take you a lot of extra setup time on your own.
Less space - If you are solo mining, you need to keep your own copy of the blockchain. Pools handle all that by themselves.
It is easier - There is a low less setup required to do pooled mining, especially when we are talking about merged mining and so forth.


private key to wif - need help converting to base58encode (step 6 to step 7) I am trying to learn more about how bitcoin addresses are created. I am following along with the tutorial at https://en.bitcoin.it/wiki/Wallet_import_format

I undertsand how they do the first six steps however I do not understand how to go from step 6 to step 7

they have 800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
and they get the private key of 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

I have read from here that I need to do put the version byte in front which is 00 so I have

00800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D

then I need to do sha256(sha256(result)) = 74944C34 (first 4 bytes)
then I have

00800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D74944C34

then I am running it through this test vb.net code (I will put it in a loop once I get it working)

Dim number As BigInteger = System.Numerics.BigInteger.Parse("00800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D74944C34", NumberStyles.HexNumber)

Dim count As BigInteger = number / 58
    Dim remainder As Integer = number Mod 58
    MessageBox.Show(count.ToString())
    MessageBox.Show(remainder.ToString())
    count = count / 58
    remainder = count Mod 58
    MessageBox.Show(count.ToString())
    MessageBox.Show(remainder.ToString())
    count = count / 58
    remainder = count Mod 58
    MessageBox.Show(count.ToString())
    MessageBox.Show(remainder.ToString())

for some reason the numbers are 48,37,3 but this does not line up with the chart on the second link and the answer which is 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

can someone please show me what I am doing wrong and help me understand the base58encode?

thanks

Version byte 0 is for addresses, for an uncompressed private key you want 128.

https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes


How hard is it to alter a block after it was found? Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block? Would he have to solve the modified block from the scratch or is there a point he can resume the solving process?

Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block?

It is impossible. The solved block depends on every byte of transaction data, nothing can be changed. It is important that it be this way. What if I could broadcast a solved block but leave out the transaction where I sent coins to someone else, essentially reverting my spend? That would make for an insecure system.

  Would he have to solve the modified block from the scratch or is there a point he can resume the solving process?

It is basically like starting over. This is mainly because of the merkle root in the block header. Think of it like a function that depends on every single byte of the transactions, and if any of the transactions change then the function output changes completely.

See this for more info on merkle trees in bitcoin: What is the Merkle root?

EDIT: I wanted to add this mining analogy that I find useful.

Each hash that the miner computes has a chance to solve a block. Mining is basically like taking a video of yourself flipping 256 coins, trying to get a long string of heads. How long the string of heads needs to be is determined by how many other coin flippers you are competing with. If you get a long enough string of heads, you show the proof (video) and get the reward. Otherwise, you just try again. You essentially start over each time you do a new hash (so billions of times), and changing your block data doesn't make you any more or less unlikely to flip the coins successfully.

Notice how it takes a lot of work to flip the heads successfully (it would take you many tries, where each try is really easy), but very little work to verify that a video of coin flips is legitimate.


How long does a payment take to appear in my wallet, If not how do I reacieave it? Yes how long does it take for a payment to appear in my wallet, on Bitcore, if it doesnt how do I reacieve it? Because it's been 15 hours but still havent seen it

Most wallets will show you incoming/outgoing transactions as soon as they appear on the network. If you are not seeing a transaction, it is possible that your node (if you're using Bitcoin Core or a similar full client) is not fully synced yet, or that the node your light wallet connects to isn't fully synced. You can fix this by either waiting for your node to sync, or connecting to one that is synced.

During times when the mempool is full, nodes might drop transactions with low fees depending on how large their mempool is. At the time of writing, the mempool is quite empty, so this should not affect you.

If you are using a hosted wallet such as blockchain.info or an exchange, their systems may have not been able to detect your transaction, and you should reach out to their customer service.

You can also ask the sender for the tx id and use a block explorer to verify that the transaction has been confirmed successfully.


How should one manage the Bitcoin blockchain on a Linux laptop with limited storage? I want to run Bitcoin-Qt on a laptop that has limited storage (it has an SSD and is used for many purposes that all require a bit of hard drive space). Assuming these hardware limitations, what would be a good way to manage the blockchain?

So, to be clear, I cannot store the blockchain on the laptop and I want to be able to make regular transactions portably on the laptop.

Starting with Bitcoin Core 0.12.0, due out in Jan/Feb 2016, you'll be able to add the prune option to your configuration file to only store the most recent blocks.  For example, if you specify prune=5000, you'll only store as many of the recent blocks as fit into 5,000 MiB of disk space.

On top of that, you'll also have to store the UTXO database, which is currently about 1.2 GiB and growing, plus maybe a few megabytes of other things like the binaries themselves and your wallet.  On Bitcoin.org, we're saying that 5 GiB is a reasonable minimum for now.

Note that Bitcoin Core 0.11.* includes a prune feature, but in those versions it disables the wallet.  (This feature was initially targeted at miners who use mining software to manage payout addresses, and it was considered unwise to have regular users use the feature until it got more testing.)

If I were you, I would consider the feature somewhat experimental and make sure to maintain backups of the wallet (which is good policy anyway, of course).


Lightning mainnet peer list? I just set up c-lightning on mainnet and I'd like to open a channel but I can't find a list of node ids and ip addresses. Does anyone know where I can find this?

Here's a site with all the nodes on mainnet
https://1ml.com


How can Ripple trust lines be exploited to scam unknowing people? This ripple forum post says

    moocowpong1 wrote:
    "She might also do this for free if she has IOUs from GatewayB and wants to convert them to GatewayA IOUs."

  She might also do this without knowing, if she has empty trust lines with both gateways (that's the core of all those stupid scams people are attempting to do)

I'm still trying to understand ripple, what to do, and what not to do.  This post in particular is a bit confusing since I don't understand:

Is an "empty" trust line equal to a trust line of zero dollars?
Does a trust line of zero dollars have any risk to the truster?
How does this scam work?
What other scams would take advantage of Ripple's unique way of working?

See the Ripple Trust Lines topics in the Ripple forum.
In this context "empty trust line" probably means a trust line with a zero balance but a non-zero limit. Such a line indicates to Ripple that you are willing to accept a balance of the specified currency from the specified issuer.
Note that the forum topic you refer to was written before the client added support for the server-side "no rippling" flag. This is implemented backwards in the client as an "Allow Rippling" checkbox which is not checked by default. What that means is that if you use the default to create two trust lines the Ripple system will not allow funds to "ripple" between them. Trust lines created before this option was present, or created with the checkbox selected, are allowed to "ripple"; you overall balance will stay the same but it can move (within the trust limits set) to/from a trust line that has "Allow Rippling" enabled. This is an incredibly powerful and useful feature.
So in short the "scam" is to get someone to foolishly extend a trust line to an account the attacker controls for a currency that they hold a balance on (or will in the future hold a balance on) and have the user check "Allow Rippling" on at least one of those trust lines. Then the attacker can make a payment that "ripples" through the victims account "taking" their positive balance and replacing it with a worthless balance they have no intention of redeeming.
To avoid this simply do any one of the following:

Only ever add a trust line to a Ripple account that you trust. Don't tell Ripple you trust someone that is untrustworthy. Only set the limit to an amount you're willing to risk.
This is incredibly basic and obvious but sadly there are people willing to blindly follow pretty "click here" picture instructions to do all kind of unsafe things to their accounts. There is no reasonable technical measure to protect these people from themselves. An attacker could just as easily claim they need your Ripple secret or your pass-phrase in order to send you a payment and some non-zero number of people will foolishly give away complete access to their account.

Leave the "Allow Rippling" checkbox unchecked unless you know what you're doing.

Or even more simply: don't randomly click things or make changes you don't understand on a system that involves your money just cause some random place on the internet tells you to.


Can I log-in to my wallet on new PC using just my wallet number and passphrase? I was into bitcoin years back. I just stumbled upon my wallet number and passphrase. Can I use these info and sort of log-in using any client I can download online?

It depends what you mean, but the answer is probably "yes" either way.

Traditional wallets use a wallet.dat file, often encrypted with a password.  In this case, you would need the file and the password in order to use your wallet on a new computer.

Hierarchical deterministic wallets (HD wallets) use a single seed (possibly what you are calling the "wallet number") to regenerate all the addresses in a wallet, thus recreating the wallet.  Often times this seed is stored as word seed (possibly what you are calling the "passphrase"), meaning several randomly generated words that can be fed into an algorithm to regenerate the wallet seed, which in turn regenerates the whole wallet.  If this is what you mean, then you could restore your wallet with either just the seed, or the passphrase.  How to accomplish this from a UI will be determined by the particular wallet you are using.


Can anamurminers.com be trusted? I'm thinking about ordering two 63 GH/s Bitcoin miner's from Anamurminers.com Also see: http://anamurminers.com/asic-miner. Can this company be trusted? They say they can ship two to the UK straight away.

There's no way this is legitimate.

Domain is less than a month old
All product photos can be found elsewhere on the web. http://www.stss.ru/products/workstations/tesla/RX240T8.2.html http://www.fractal-design.com/?view=product&prod=94
Address/phone number/name on Contact Us page differs from address/phone number/name on WHOIS record.
They say their miner connects over USB. However, they don't have any drivers for it on their website, or say what OS it works with.
They said that they're too busy to take a video, or post an non stock-photo image, but they would in a week. They said that 10 days ago.
They claimed that they designed, wrote, sourced, soldered, and tested the whole thing, front to back, in 3 weeks. Then somebody on bitcointalk pointed that out, and now it took them 3 months! Still implausible, though. Unless you're willing to pay insane markups, your shortest turnaround time on an ASIC is around 6 months, and that's if you already have your design done.
They offer local pickup (in the Czech Republic)
This gem:

  Due to Czech law, we MUST, give you back your money even after 14 days, if you are not satisfied with the product.

I doubt that.

So yeah. Scam. I'm guessing that Antonio Barreto is the brains of the operation, and Anamur Silif is the fall guy.


Optimising the inputs for a transaction I have a list of unspent outputs.
Let's say: 0.4 BTC, 0.6 BTC and 1.0 BTC.
Now I want to create a new transaction for a 0.5 BTC. How I understand it, it would be best to take the 0.6 BTC output as input, and add 0.1 output as change.
The simpler way would be to just start at the beginning and add up inputs until I reached the desired amount. But that seems stupid...

How is this being done by the usual bitcoin clients?
What's the best way of finding the most optimal unspent outputs?

Every client has different selection criteria based on fees, age of the outputs, and other factors that impact the ultimate fee and priority. Normally older outputs are preferred as they incur less fees. You would probably want the 0.6 BTC output as you'd need 0.0001 BTC for the fee, sending 0.9999 to a new change address.

There's ultimately no "proper" method as this is wallet functionality and not core protocol.


Is the Ledger Implementation of BIP39 Generation Not Following the Spec? According to the BIP39 spec, invalid checksums should be displayed by software.

However, Ledger's BIP39 generation tool (which looks like a copy of Ian's tool), will not show an error for invalid checksums.

Example phrases to test with:

Correctly Generated Recovery Phrase:
square cactus nurse pond share rescue prepare bottom suffer speed will tomorrow

another "valid phrase" (different but invalid checksum):
square cactus nurse pond share rescue prepare bottom suffer speed will account

another "valid phrase" (different but invalid checksum):
square cactus nurse pond share rescue prepare bottom suffer speed will acoustic

For a 12 word phrase, if you split the 2048 wordlist into 16 word blocks, every 1 word out of the 16-word block will not produce an invalid mnemonic (or checksum) error.

My two questions:

Is this going against the BIP39 spec?
Why does this code allow for 1 out of every 16 words of a block to be deemed as "valid"?

Those are valid mnemonics with valid checksums. In  the bip39 spec is the following:

  The following table describes the relation between the initial entropy length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words.

  CS = ENT / 32

  MS = (ENT + CS) / 11

|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |   132  |  12  |
|  160  |  5 |   165  |  15  |
|  192  |  6 |   198  |  18  |
|  224  |  7 |   231  |  21  |
|  256  |  8 |   264  |  24  |

As per the top row, 12 word mnemonics have 128 bits of entropy and 4 bits of checksum. That means any random 12 word mnemonic has a 1 in 16 chance to have a valid checksum.

The "blocking" of the valid final words instead of a totally random distribution is because the checksum bits are appended to the end of the entropy bits. So for every first 128 bits, there is exactly one valid final four bits. Bits are mapped to words by just counting down the alphabetically-sorted word list for each 11-bit chunk. So the first 128 bits determine the first eleven words and which "block" of the wordlist you are considering, and then within that block only one word corresponds to the correct checksum.


Where can I find a chart of the daily supply? there is the blockchain.info one for total supply but that very low resolution.

I really was a graph of the actual new bitcoin mined on the market on a daily basis because it seems like a strangely elusive number given it's sigificance.

I know it's somewhere in the region of 4300 BTC per day, and probably quite stable. The stability itself though would be interesting to chart because it's not going to be perfect.

Failing all that, the blockchain has this information in it doesn't it. Perhaps I'll have to figure out now to plot it.

Such a chart is trivial to create yourself by scraping blockchain.info. The following bash script will do just that:

#!/bin/bash
END=$(date -d 'today 00:00:00' +%s) # Today 00:00:00
START=1354147200 # Midnight 2012/11/29 (days after reward halving)
DIFF=86400 # Number of seconds in a day

for i in $(seq $START $DIFF $END); do
  # Blockchain.info uses milliseconds, hence the additional 0s
  BLOCKS=$(curl -s https://blockchain.info/blocks/${i}000 | grep '(Main Chain)' | wc -l)
  BLOCK_DATE=$(date +'%Y-%m-%d' -d @${i})
  echo $BLOCK_DATE, $BLOCKS
done

This iterates over all days since the block reward halving day (2012/11/28) and counts the blocks that have been mined on that day. The following plot shows the number of blocks per day. Multiply that by 25 and you get the daily supply of bitcoins entering the system.

Notice that the notion of day depends on the timezone you're in, and blockchain.info appears to use GMT timestamps. Also blockchain.info uses the timestamp included in the block, which might be off for up to 2 hours, but that should even out in the long run.

You can find the script and data here.


How To Traverse Bitcoin Addresses in HD Wallet It appears that there are many way to traverse Bitcoin addresses. I am looking best practice, and I am also looking for the documented logic of how common wallets do it so I can replicate their behaviour.

For example, Trezor creates the first address at this location:
m/49'/0'/0'/0/0, and then the next address will be m/49'/0'/0'/0/1, and so on. So, it appears that it would be easy to just use an iterator over the last digit.

But, when you spend from m/49'/0'/0'/0/0, it moves the leftover to m/49'/0'/0'/1/0 . So, suddenly, I not only have to iterate over the last digit, I also have to iterate over the penultimate digit. I could have said "second last", but I said penultimate because it sounds more intelligent.

Is there standard practice for traversing addresses? Something like, keep traversing over addresses until you hit an address with no transactions? Or possibly say three addresses in a row with no transactions? Or is this really the wild west and we just do whatever we feel like?

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

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

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

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

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

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

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

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


Clarification about lightning network When I run a lightning node, I have to set up a lightning channel with, for example, a highly connected node.

Here a first question: When I set up a lightning channel with a node, have I need to put some bitcoins in it?

Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), will I have to open another lightning channel with Blockcstream? Or the previously synced channel will be used to let me buy from Blockstream?

Thank you.

When I set up a lightning channel with a node, have I need to put some bitcoins in it?

Generally, yes. The person who initiates the channel creation process (i.e. the person that says "I want to open a channel with you") is the one who funds the channel.

  Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), will I have to open another lightning channel with Blockcstream? Or the previously synced channel will be used to let me buy from Blockstream?

Not necessarily. If your channels are connected to other nodes who have channels with other nodes and eventually a channel with the merchant (which is likely the case), then you do not need to open any new channels. You can make your payment route through the Lightning Network and it will reach the merchant.


how to get the sender's address in bitcoinj I'm trying to modify the simple wallettemplate to get the sender's address in the transaction list. However since TransactionInput.getFromAddress() doesn't exist now and getConnectedOutput().getAddressFromP2PKHScript() is deprecated, I don't know which is the right way to do so.

Bitcoin transactions don't have a sender's address.

What you're doing is inferring what address previously controlled some or all of the funds involved in the transaction. But:

Previously controlling the funds doesn't mean you found the sender. In case the coins were held by a custodial exchange, the address will be the exchange, and not the sender of the funds. In particular, sending coins back there won't make them reach the right person.
Transactions can be jointly constructed using multiple participants. You can only guess which is which.
The script that previously controlled the funds may not have an associates address at all.

If you want to know what the sender's address of a transaction is, ask the person who sent it (for example if you need a refund address, ask it before showing an address to pay to). If it's not a transaction you're involved in, it's probably none of your business.


Track transactions for a list of addreses not in a wallet I am developing a payment gateway for BTC and have the following problem. I have bitcoind wallet and awaiting of some income for some some list of generated addresses. If i have received something on a the address I remove it from my wait list and make transaction complete. There are a lot of online services that allows me to look transactions or even some JSON-rpc solutions like blockchain.com allow to do it.

But I am wondering if it is possible to do it just using bitcoin-cli RPC protocol and without adding all ammount of addresses to the wallet.

Bitcoin Core does not allow you to track transactions for addresses that are not in your wallet.

If you wish to do this, you will need to maintain a separate index outside of the bitcoind node, either by scanning each incoming block for transactions involving your address, or by using an external api such as Blockchain.com or insight to query for your addresses.


Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond? How fast could you possibly run a blockchain like bitcoins'? Could blocks be added as fast as a microsecond while still having a functional currency?

You couldn't make functional Bitcoin-like fork with that fast of block mining. There is a tradeoff between speed of block creation and consistency of the network. In Bitcoin the blocks are created infrequently enough that the entire network can agree on the canonical blocks quickly and transactions can propogate quickly enough of that they tend to get included in blocks fairly quickly (assuming that miners aren't ignoring them due to low/no fees).

If a fork aimed for a block generated a millisecond that would imply that network latency would result in thousands of blocks happening before you could even see the first one. In Bitcoin there are occasional forks of the blockchain due to propagation delays, but they are very quickly resolved by the network. A fork with millisecond blocks (and a large user base) would certainly have thousands of competing forks at any given time, and it would take tens of thousands, maybe even millions of confirmations before it became clear that a fork was dominant. (By which time, there would be thousands of forks of that fork.)

Plus, even without any transactions, each block has a minimum size of overhead, so the size of the blockchain would be growing at an outrageous rate. The same would apply to network bandwidth: the amount of chatter between the nodes would be outrageous: none of the nodes could keep up with the volume. Especially given that the volume would have so much duplication between all of the competing forks of the blockchain.

As Colin Dean points out, Litecoin has established a 2.5 minute target. So changing the target block generation speed is possible. But every time you go lower, the overhead and consistency gets harder.

What's the theoretical maximum? It's hard to say since so much depends on how globally distributed and large the network is. My wild guess, given current technology: anything much less than a minute would have a lot of forks and a lot of overhead. Anything less than a few seconds would almost certainly fail to achieve any kind of stable consensus about the blockchain.


How do I get private key from Bitcoin Wallet for Android I had BTC in the Bitcoin Wallet during the hard fork and would like to get my bitcoin cash. I moved all the BTC out of the wallet before bitcoin gold happened.

Export it with an export option or derive it from your word seed using a website or other tool.

I'd need more specific information to say more than that.


How to convert xpub ypub and zpub in Ruby I'm looking to convert a Bitcoin extended public key from one format to another in Ruby.
In JS I've found https://github.com/jlopp/xpub-converter/blob/master/js/xpubConvert.js and Python https://github.com/lian/bitcoin-ruby/blob/master/lib/bitcoin.rb, from which I try to understand how it works.
But in Ruby I can't wrap my head around it. I use the Bitcoin::Util and my code is as follows:
require 'bitcoin'

include Bitcoin::Util

xpub = 'xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz'
prefixes = {
  xpub: '0488b21e',
  ypub: '049d7cb2',
  zpub: '04b24746'
}

decoded_key = decode_base58(xpub)
zpub_key = encode_base58(prefixes[:zpub] + decoded_key[8..])

puts zpub_key # => zpub6r8o2p9croV2A7Gh2VZn42iEEv7QCxJrXyqWDUcV7aMapn2nY464gJKzfFTs2Ry4UnCFT1pmvSru6u1KX4GyRs2ti4SYydbtH17TgCSRAgQ
puts base58_checksum?(zpub_key) # => false

The checksum is invalid and I don't understand how to make it work

I'm not sure about ruby, but here's what's happening in practice.
Take any xpub:
xpub6DBfkACRRWo6B9Fo31Ko6P7M92Yb3rdbuXb81Ls7aDCaZsMr1tyvZWHAHz1exRZuTBspafkPTynwoWL5o3i4WiJX4P3SyGQxNpxQLaUnB2c

Decoded to hex:
0488b21e03d0888900800000002a2c58c384bf2904e3b251fe5367e21f8acd97f94481709207c7487b9aec159a022ff4a6a6d463c3aadc35366346580f5f95085912d0910c178d2c3d33774ff700a10d285d

Notice the first 8 characters in the above hex version 0488b21e. What you need to do is replace those 8 characters with the version bytes you want and then re-encode back to base58.
For example, if we want to do zpub04b24746 we'd change the hex string to:
04b2474603d0888900800000002a2c58c384bf2904e3b251fe5367e21f8acd97f94481709207c7487b9aec159a022ff4a6a6d463c3aadc35366346580f5f95085912d0910c178d2c3d33774ff700a10d285d

Re-encode to b58:
zpub6rrCMVYFist3sje2hiu3WZJMUxqUw6cbjkdZa8etLDxLg4zJXDK3odbSLPvpxEskGU7S5cwWPJW3a5ZDESY67Bfio4SJ963vvH5h7jFyqw2

That's it! Regarding the checksum issue see answer: https://bitcoin.stackexchange.com/a/98816/26873
IT IS IMPORTANT to note the account derivation path is already baked into your original extended public key. So let's say you have an ypub that uses BIP49 derivation path, BIP49 will remain even if you change it to xpub, or a zpub. If you're looking to change to BIP84 you need to start from the seed, then derive the path m/84'/0'/0'/0, then change it to a zpub. Simply changing from xpub to ypub or zpub does not change the derivation path.


What can be done with a bitcoin besides exchanging it for goods or services? Some people have described a bitcoin as a commodity, but every commodity I see on this Wikipedia page seem to have a non-financial purpose, which also gives it a financial value.

What can be done with a "Bitcoin" (if anything) that has a non-financial purpose?

A Bitcoin can be used to permanently trace the association between different public keys.  For example a user can send a transaction to a second user and publicly and permanently link the accounts.  This may have utility in Web Of Trust scenarios.
The low value bits of an individual bitcoin can cheaply store metadata.
Saving them as a collectors item
Sharing (p2p style) a small amount of data


Is it possible to split a key for transaction signing without using multisig? I am developing a wallet API, but I don't want custodial control of the user's funds.  For reasons I won't explain here, I don't want to use multisig.

But I want the advantages of a 2 of 2 multisig.  I want the client to sign a transaction, and then send that signed transaction to the server.  The server will then finish signing the transaction and push it to the network.

Is this theoretically possible?  Does something like this exist yet in practice?

In summary, I want a way for the client and the server to sign a transaction together without either one having the private key.

There is a way for you to do so, but it involves something called Threshold Signatures which lets you do most of what you want (n-of-n without multisig). The thing about threshold signatures is that they require at least 2 round trips. That is, A and B have to exchange partial signatures a few times before the signature is valid. For 3-of-3 and higher, you need 3 trips to each person in order to produce a valid sig. Also, threshold signatures haven't really been implemented in any software than the one the Princeton researchers made.

The other method of sort-of doing something like what you want is using Shamir's Secret Sharing. I know Armory implements this for fragmented backups but you can't use the sharded pieces for actually signing, only for recovering the actual private key.


Signature verification in python When trying to implement OP_CHECKSIG, I am unable to figure out how to do the actual signature verification in python (python3)

I obtained the signature, public key, and hashed message digest of a transaction, and now I want to verify the signature.

message = '692678553d1b85ccf87d4d4443095f276cdf600f2bb7dd44f6effbd7458fd4c2'
pubkey = '042e930f39ba62c6534ee98ed20ca98959d34aa9e057cda01cfd422c6bab3667b76426529382c23f42b9b08d7832d4fee1d6b437a8526e59667ce9c4e9dcebcabb'
signature = '30450221009908144ca6539e09512b9295c8a27050d478fbb96f8addbc3d075544dc41328702201aa528be2b907d316d2da068dd9eb1e23243d97e444d59290d2fddf25269ee0e'

Since python-ecdsa requires 64 byte input for creating the verifying key, I removed the first byte myself.

pubkey = pubkey[2:]

I also extracted r and s from the DER encoded signature, and concatenated these to create a 64 byte signature as python-ecdsa requires.

r = '9908144ca6539e09512b9295c8a27050d478fbb96f8addbc3d075544dc413287'
s = '1aa528be2b907d316d2da068dd9eb1e23243d97e444d59290d2fddf25269ee0e'
sig = r + s

However when I try to verify the message, I get a BadSignatureError signifying that the verification failed.

from ecdsa import VerifyingKey, SECP256k1
vk = VerifyingKey.from_string(bytes.fromhex(pubkey), curve=SECP256k1)
vk.verify(bytes.fromhex(sig), bytes.fromhex(message))

I am looking for a way to verify signatures that I have extracted from bitcoin transactions.

Thank you.

The way that VerifyingKey works is that it will actually hash the message before it verifies. The default hashing algorithm is sha1, so you will need to specify it to be sha256 as that is what Bitcoin uses. Furthermore, you are passing it the fully hashed message. What you need to do is pass it the step before hashing the message. Since Bitcoin uses SHA256 double, you need to give it the result of the first SHA256 hash and let it generate the second SHA256 hash by itself.

So your message should actually be

083867478cb0d1d8bb864175bbc49728cffcc114bc2e762c6df64f2c965a9a66

and your verify call should look like

vk.verify(bytes.fromhex(sig), bytes.fromhex(message), hashlib.sha256)


How to connect LND to bitcoind RPC with authentication cookie stored in a custom folder? I configured bitcoind RPC to authenticate clients with an authentication cookie. However I cant figure out if it's possible to use this method with lnd while connecting to bitcoind RPC.

I would like to clarify that I'm running bitcoind and lnd in two separated docker containers that share a volume where bitcoind save the authentication cookie. The problem is that lnd doesn't allow to specify the folder in which it could find the cookie... In bitcoin.conf for exemple you can specify the path where you can find the authentication cookie of the tor control port for example...

Someone knows how to do this in lnd ? Is it possible ?

Thank you!

It is supported according to the LND installation guide

NOTE:
The auth parameters rpcuser and rpcpass parameters can typically be determined by lnd for a bitcoind instance running under the same user, including when using cookie auth. In this case, you can exclude them from the lnd options entirely.


Accidentally sent to my own receiving address, will I get back my bitcoins? I mistakenly pasted my own Blockchain.info receiving address into the recipient field when I was trying to send BTC to a friend. I usually receive either a "send" or "receive" notification in my records, but this time I got a "transferred" notification. Even though it was my own receiving address it took 100 confirmations and blockchain.info never returned my BTC back to my own wallet. I'm not asking for my fees to be returned but about the whole bitcoin I sent. Do you think that I will get back my BTC even if I used my own receiving address?

Bitcoin doesn't know that the recipient address is also yours. Therefore, while you sent the money to yourself, it looks like any other Bitcoin transaction to any other network participant.

To your wallet provider (blockchain.info) it is obvious that you control both addresses, so they call it a "transfer" instead of a "send".

As you've sent it to your own receiving address, you should be able to see it counted towards your balance. If it hasn't been, get in touch with blockchain.info and request that they help you rectify it.


Bitcoin transactions over Ripple Network I am interested in using the ripple network in conjunction with bitcoin transactions, but am curious as to interplay between the ripple ledger verification and the bitcoin blockchain verification.

I understand that the ripple network operates as essentially a series of IOUs and allows the ledger to be verified in an order of magnitude of seconds, however, a Bitcoin block takes on the order of magnitude of 10 minutes.

Does this mean that ripple transactions that involve bitcoin are entirely off the chain transactions or am I somehow missing something? I am just trying to get my head wrapped around the seemingly hand-wavy aspect that something that takes 10 minutes to verify can be used in a transaction that takes only 5 seconds to verify.

As you already have described, Ripple transactions are based on exchanging IOUs. As such, when you trade bitcoins on the ripple network, you are trading IOUs denominated in Bitcoin owed to you by some party, e.g. BTC owed to you by Bitstamp. Therefore, as long as the transaction is between Ripple users, it is completely off-chain and can be confirmed within seconds.

However, there is at least one Ripple Bitcoin bridge which is offered by Bitstamp. This bridge allows Ripple transactions to directly end in on-chain Bitcoin payouts. It works by having a Ripple transaction send money to Bitstamp, who then converts the amount and sends Bitcoin to the recipient. The Ripple side takes the regular short time to confirm, the Bitcoin side is a regular on-chain transaction though, which will be confirmed as usual in the next Bitcoin block.


What happens when moving BTC from one wallet to another on blockchain.info with 0 fee? i just tried to move some btc between wallets on blockchain.info with 0 fees and I'm getting this: http://prntscr.com/2bmay9  --- it shows 0 btc but says its moved. what happen here? its been over 24 hours already.

You moved 0.8 BTC from 1DbYDYkehPSFrg9zwHY93ZcqmwFLQggw81 back to 1DbYDYkehPSFrg9zwHY93ZcqmwFLQggw81. So in essence, you didn't really move anything.


Buy coins using a australian bank account from Germany I am German living in Germany but do own an Australian bank account. I would like to use that money to buy bitcoins but somehow am not able to at the big exchange markets.
Whenever I identify myself it assignms me a German profile (which is fine) and only allows money transfer from european countries.

Is there a simple way to do this?
Sorry for this newbie question...

Use one of the Australian exchanges such as coinjar.com or coinspot.com.au. They offer methods such as POLI and BPay (which are specific to Australia) for deposits from an Australian bank account.

The rates are slightly more expensive than coinbase but I doubt there's any easy way around that.


How do I list all unique scripts from blockchain? How do I list all unique scripts in the block chain, and their count (n-times-used)?

If you are looking for actual input scripts then the answer is simple: if there are n outputs being claimed then there are exactly n distinct scripts that are used exactly once. This is because each script includes a signature for a particular output that is being claimed, and they should be unique (that is excluding random collision, which are extremely unlikely).

If you are looking for output scripts then the number of distinct scripts is likely to be the number of addresses that received an incoming transaction, as they contain the addresses that may claim the output.

This is ofcourse just for the standard transactions in which you put up a claiming condition by requiring a single signature from an address and then provide the matching signature when claiming it.

More interesting could be the number of distinct script formats. That is counting the unique types of scripts, for example by just replacing all signatures and hashes with a placeholder and then counting them.

As far as I know blockchain.info does not currently offer such a functionality, but they might be interested to include it.


does blockchain.info have everyone's private key? I'm looking at blockchain.info's FAQ page, and they describe the wallet creation scheme here: https://blockchain.info/wallet/technical-faq (please scroll down to the Please describe the wallet creation routine. section)

Because their wallet encoding tool is in Javascript, which is clientside, the user can trust that the encryption key cannot be on the server because Javascript must be all clientside code?

Is there any server side method in which the site could maliciously collect this data, therefore compromising blockchain.info's integrity?

Could blockchain.info suddenly change a line of code in their javascript, for say, a few minutes, and begin storing the pre-encrypted data into their servers without many people noticing? They could use this method to collect private keys from random samples of people, and would likely get away with it.

No, they have everyones encrypted private key. The private key get's decrypted locally on your client.

And of course they could change some lines of code and collect your private key. But this is true for every bitcoin client (thin client or not). That's why it is important to get the client binaries from trusted sources (and deterministic build).


Does blockchain.info backup wallet include also the next addresses The standard client's wallet includes a key pool of 100 extra pre-generated addresses, which are the next ones to be "generated" when you ask an extra address.

Does the blockchain.info's backup wallet do such a thing, too?

No, it doesn't. At least not from what can be seen in the "Export Unencrypted" option and I doubt that it would be any different using the encrypted option.


Is it possible to use something besides sheer computational power as the limiting factor on block release? Why hasn’t anyone tried to create a blockchain that, rather than using computational capacity as the hash scarcity test, just has a direct limit on how many times a particular wallet can make a guess per day? (or something like that..)

I’m just thinking that the whole arms race for processing power means that the system isn’t really as democratic as it initially seems. Like sure, you don’t have a fed that controls inflation, but every new crypto currency from now on will be mostly owned by whoever has the most ASIC farms won’t it?

direct limit on how many times a particular wallet can make a guess per day? (or something like that..)

Guess per day for what?

You can't limit it by wallet since you can't know what addresses are in a wallet. To the network, there is no such thing as a wallet (and technically no such things as addresses or Bitcoin objects either). If you were to limit it on a per address basis, then people would just generate infinite addresses (because they are essentially infinite and you cannot prevent people from generating as much as they want) to do their "one guess per day".

  but every new crypto currency from now on will be mostly owned by whoever has the most ASIC farms won’t it?

No, that is completely incorrect. Miners are not an absolute authority and do not have a final say on anything. The consensus rules are something that everyone who uses a coin follows. If any consensus rule is violated by a block or transaction, that block or transaction will be rejected by everyone who is validating consensus rules, i.e. the full nodes. So no, miners don't control it or own the currency because they cannot force changes onto the community and it would be pointless to mine a coin if you are the only holder of it (i.e. there is no market so no value).


Will this bitcoin mining strategy work? I'm new to bitcoin, and my knowledge of bitcoin is quite garbled and messy (I have only a vague understanding of Satoshi's original white paper for bitcoin......)

I've been reading up on bitcoin mining lately, and I just thought of a mining strategy which may or may not work.

What I want to do is this:

(1) Obtain the hash of the previous block to use as a component of my new block. This previous block hash can be updated accordingly if a new block is added into the blockchain.

(2) Based on the previous block hash, I calculate the possible block header combinations of the nonce, the version number, the timestamp* and the Merkle root. The goal is to simply find a valid block header which has a lower hash value than the current target.

(3) Make several bitcoin accounts, and execute a transaction based on this pre-constructed block header. For example, based on the pre-constructed block header, I have to execute a transaction at a specific time, with a specific Merkle root, etc. Once my transaction has appeared in the mempool, I can immediately submit my pre-constructed block header to verify the transaction - and earn bitcoins in the process.

*: The timestamp should be within a reasonable range - (a) greater than the median of the past 11 blocks, and (b) be within 2 hours of the network adjusted time. Otherwise, the timestamp would not be considered valid by the bitcoin network.

The potential advantage (at least, that's what I think) of this strategy is that I can earn bitcoins 100% of the time because I already know the winning nonce to the puzzle, putting the other miners at a disadvantage.

Is this even remotely feasible? Does this take more computing time and power than the typical bitcoin mining process? Or am I missing something?

(2) Based on the previous block hash, I calculate the possible block
  header combinations of the nonce, the version number, the timestamp*
  and the Merkle root. The goal is to simply find a valid block header
  which has a lower hash value than the current target.

The block header is 80 bytes size:

version: 4 bytes.
previous hash: 32 bytes.
merkle root: 32 bytes.
time: 4 bytes.
bits: 4 bytes.
nonce: 4 bytes.

Miners iterate the nonce (4 bytes), and the fast ones the extranonce (4 bytes more). The other items are already known, they get them from the pool.

You propose to iterate nonce (4 byte) + version (4 byte) + merkle root (32 byte) to find a target hash faster than them. I belive it will not work.