text:
What is the exact formula for calculating transaction fees?
According to the Wiki:

If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.

What is the exact formula that determines the transaction fee?

See GetMinFee() in main.h for the code which determines the minimum transaction fee.
The part you're describing is implemented as follows:
// Raise the price as the block approaches full
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
    if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
        return MAX_MONEY;
    nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}

where:

nBlockSize depends on who we are:

if we're a user making a new transaction, nBlockSize is 1
if we're a node deciding whether to relay an incoming transaction, nBlockSize is 1000
if we're a miner deciding which transactions to include in a new block, nBlockSize is the size of the block we're building before adding the new transaction

nNewBlockSize is the size of the block including the new transaction
MAX_BLOCK_SIZE_GEN is 500kB
MAX_MONEY is 21 million BTC (all the money in the world)

so it's saying:

if we're either deciding whether to relay or mine the transaction, and adding the transaction would make the block over 50% full:

never allow a transaction that makes the block 100% full
otherwise scale the fee up by a factor of 500kB / (500kB - nNewBlockSize)

Note: by rearranging the symbols, we get exactly what Meni wrote in his answer:
Fee = Normal fee / ((500kB - size) / 500kB)
         = Normal fee / (1 - size / 500kB)

That rule is pretty strange, and doesn't look stable to me, since it's against the miners interests.

It's not against the miner's interests. If the miner fills up the block with low-fee transactions, he loses the opportunity to get high-fee transaction in there. Remember, not all transactions are the same size, so you can't just go in fee order. (The optimum algorithm would be to sort the transactions into two pools, one for fee transactions in fee-per-byte order, the other for free transactions in priority order. Fill a block from the first pool in order if possible until no more paid transactions fit, then take as many from the second pool as fit.)

@DavidSchwartz I argue that miners will converge to a fee-per-byte auction instead of this algorithm because that's in their interest. You agree with the fee-per-byte part, but disagree with the current algorithm being against miners interest. So your comment seems inconsistent to me.

@CodeInChaos: The effort required to act in their interest would actually make it not in their interest overall. The difference between an ideal algorithm and the current one, today, is about 0.02% or so. It's like driving across town to pay a penny a gallon less for gas.

Even if the algorithm wouldn't require a fee, if the the coin used for input is new a fee still could be required: http://bitcointalk.org/index.php?topic=84434.msg931988#msg931988

The other answers describe the rules currently implemented in the client, but I expect those rules to be replaced once block size limits become relevant. Since those rules aren't enforced when clients verify the blockchain, they are only guidelines, and will be violated if they're against the interest of miners.
Miners will simply choose the subset of candidate transactions that respects the limits (blocksize and signature count) and maximizes the fee.
Disregarding a few minor complications (knapsack and dependent transactions) this means that miners sort the transactions by fee/transactionSize if the maximal size is the limiting factor, and fee/signatureCount if the signature count is the limiting factor.

I don't know the formula from any authoritative source, but based on the examples in the text, it is
Fee = Normal fee / (1 - Block size / 500KB)

Or equivalently (and I suspect the actual code uses this form)
Fee = Normal fee * (500 KB) / (500KB - Block size)

Did you add the "Or equivalently" part after posting your initial answer?  There's no "edited by..." under your question, but I could swear your answer was originally half its current size.

@ChrisMoore: The author of a post can edit it during some time (5 minutes I think) without the change showing up as an edit.

@ChrisMoore: You are of course correct, as is D.H. .

Where is the "Normal fee" defined for this calculation?


text:
Address creation in standard client - random library?
Is the random library used by the standard client in any way deterministic, or can one count on it being truly random?
For example, often random libraries are initialized with seed value of the current time, like in C++:
srand(time(NULL));

But if someone was to iterate over reasonable ranges of time when a client started, eventually one would use the same seed value, and thus be able to generate the same addresses.
Is the random library used by the standard client vulnerable to such an attack, or does it also use some other variables that are unpredictable (say, temperature of the processor down  to such decimal places it becomes an unpredictable noise)?

In addition to microsecond time, Bitcoin seeds the random number generator with GUI events, /dev/urandom on Unix, and HKEY_PERFORMANCE_DATA on Windows (very random, constantly-changing data).

No CryptGenRandom on Win?

@CodesInChaos No.

It uses a cryptographically-secure random number generator, specifically the one included in OpenSSL. Generating a key from a source with less entropy than the equivalent bit strength of the key would be an inexcusable rookie coder error. It wouldn't survive in any popular open source program for more than a few days.

We would all like that to be true, but unfortunately it's not.  Debian's broken patch to OpenSSL survived over a year and a half.  It was caused by a change that reduced the entropy used.  It's certainly easier to root out vulnerabilities in open source software.  But that doesn't mean it always happens right away.

That's a much different kind of error than the one contemplated in this question. But you're right that, unfortunately as it happened, the effect was the same.

There has been some discussion on flaws on key generation entropy in standard Bitcoin client.
Check https://bitcointalk.org/index.php?topic=113496.0.
Basically, RandAddSeedPerfmon() and RegQueryValueExA(HKEY_PERFORMANCE_DATA,..) calls done in Bitcoin source code can fail without the user getting notice.
The single only reliable source of entropy in the standard Bitcoin client is OpenSSL RAND_Screen(), function which is called on initialization of the rand pool.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Chaining unconfirmed raw transactions
I'm currently working on a system that provides payouts to users from a bitcoin address as they 'burn' other assets on the site (think something like ShapeShift, where you pay someone BTC to get some other cryptocoin, and you pay this coin back to get BTC).
I'm using public apis to build and send raw transactions using bitcoinjs. However, I have the issue that I sometimes need to wait for previous transactions to confirm before I can send more out. This will often involve bitcoins that will - no matter the result of the confirmation - be mine.
Here's an example. I have 10 BTC, and I have posted a tx to User 1, sending him 5 BTC and 5 BTC back to myself. Now I am sure that I have 5 BTC in my account (regardless of whether the tx confirms) - but this isn't easy to confirm for me, especially when multiple such txs get chained and a lot more inputs and outputs get involved. How do I check and design a transaction so that I can send 3 BTC to User 2?
Can I chain unconfirmed transactions? I understand this would be dangerous if any of the transactions failed (insufficient fee, corrupt data, etc). Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?
Finally, is there a better way to do this? For an outgoing bitcoin account that only makes payments to users, what would be the best practice? Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?
I understand there is a similar question here, but it does not discuss transaction ordering, and my concern is primarily about setting up an outgoing Payment system by which I can send multiple outgoing transactions per block as payouts.

How do I check and design a transaction so that I can send 3 BTC to User 2?

You reference the 5 BTC unconfirmed UTXO for your next transaction and pay 3 BTCs to User 2 and 2 BTC back to yourself.

Can I chain unconfirmed transactions?

Yes, you can.

Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?

Yes, there is a possibility. The latter transaction will not be discarded, it will be in another node's orphan tx set so as long as that limit has not been met. So there's also the possibility that some node's orphan tx set is full and your orphan tx will get rejected outright.
Tx1 (unconfirmed, accepted) <- Tx2 (unconfirmed, not yet visible) <- Tx3 (unconfirmed, accepted && orphaned)
The above transaction chain is a valid chain of unconfirmed transaction.

Finally, is there a better way to do this?

Not quite. The recipient can use CPFP to bump the fees, so the transaction fee that pays for the entire transaction chain becomes greater. That increases the probability of immediate confirmation. Otherwise, you as the payer can use RBF to bump the fees.

For an outgoing bitcoin account that only makes payments to users, what would be the best practice?

Only pay from confirmed transactions, otherwise pay sufficient transaction fees which results in probable immediate confirmation. You as the payer would still have the opportunity to bump the fees with RBF to provide better user experience. Or you may insist your users to use CPFP to accelerate their receipts.

Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?

Exchanges don't really care about the speed at which recipient receives their fees, they usually pay a decent transaction fee so that you'd receive your transaction in "due course".

Thank you for the detailed answer.
However, I find that exchanges post transactions as soon as I've requested the payout, and I've never seen an unconfirmed output being used as an input in a tx. Is there some efficient way of running a payout system that I'm not aware of?

I suppose the reason why exchanges can manage this is because of volume or most traded coins are simply between account within an exchange, so actual blockchain transactions are not required.

My thoughts exactly at first, but looking at exchanges like Coinbase I'm not sure if they're matching orders between users or sending bitcoin from a few hot wallets. The former would be quite hard for a low-volume exchange I'd imagine.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Looking for raw historical LTC data
Something comparable -- though not necessarily as comprehensive -- to the datasets found here: http://api.bitcoincharts.com/v1/csv/
These links are all dead:
Is there a source for historical LTC trades available?
This site apparently had full trade data history: http://ltc.block-explorer.com/charts
...But that's dead as well.
help greatly appreciated!

A bit late, but better late than never.
No guarantee given for accuracy.
From day one to January 8 2016
For the first 262 days the average trading price is used as no closing price available.
Bitcoin price mainly from Bitstamp, Litecoin from BTCe so LTC-BTC is a bit different for BTCe price
No trade first couple of days ltc-dollar price established from ltc-btc and bitcoin dollar
The lowest closing price was on May 29 2012 at $0.0023.
The lowest recorded deal January 23 2012 at  1:36:42   $ 0.001302   4.20697  Litecoins changed hands at that price (did have all volume too, but gone. was just a spreadsheet, but link to it dead too)
Three days did not have any trades at all: 17.March 2012, 6.May 2012, 17.May 2012
LTC-USD
LTC-BTC

Pastebin contents will end up being a dead link just like the rest, so I'm afraid this is not a good case of "better late than never". Also, @Dave is asking for datasets, not vague prices inlined in the response.

What about intraday data?


text:
How to make PoS system work?
In a r/bitcoin I've found the following statement:

I think it should be noted that this paper covers a "pure" PoS system, but there have been some hacks to PoS systems to make them "work" (work while being insecure). These hacks include having a central authority control the coin (peercoin, blackcoin, and a ton more), making grinding more difficult but certainly not impossible along with making buying old private keys to attack difficult through having a centralized premine that makes the currency insecure to attacks from a central authority (NXT), or even making the next block signer deterministic, which solves stake grinding by substituting the problem with a problem that is probably much bigger, colluding delegates. , this also doesn't solve the problem of people rewriting history (bitshares).

Could one explain in details how to protect PoS system using full pre-mine and a central authority? Will the system be theoretically secure or still not?

If you want a system with centralized trust, I suppose you could do a 100% pre-mine, and have some checkpoints to 'lock' this, and have all nodes verify against the checkpoint coming from a trusted set of nodes. Even with this, you could have some bad players trying to cheat, and it would involve constant 'supervision' and checkpointing as needed... Why would any outsider want to use such a system, is beyond me. If we assume centralized trust, there are probably more efficient ways to build a token exchange platform anyway.
PoS can't really work for the same reason perpetuum mobile is impossible or in other words - you can't pull yourself up by pulling on your own hair.
The problem boils down to the fact that, with PoS, what you're staking and what you're winning is one and the same thing, a digital token. So, you're staking something that doesn't physically exist, to win more of something that doesn't physically exist. And the more you have, the more you're able to win. Sure, because there's a market you can say you're staking something of 'value', but if you got it cheap in the first place and it appreciated 100x in the meantime, the cost for you to start foul play is not at the new price, but at the old price at which you got it. Also, if you're happy with 100x, you just dump it on the market, exit clean and let some other poor soul be exposed to the risk. There's no 'investment' you can lose, because it's all digital - both the prize and the stake.
With PoW, your stake is something physical. You used 'real' money which still stands for actual human work performed, invested into specialized hardware, and consumed hard, physical energy to win the prize. Why this is important? Because energy can't be created out of thin air - you can't cheat laws of physics. This means that the punishment for attempts at cheating will always cost you real-world resources and not some digital token which came into existence from thin air in the first place. Even if you sell all your winnings, it doesn't erase your investment/stake. You still have the hardware you invested in, and there is still incentive to keep it running as long as the market gives value to the token it creates. You can't get rid of it at 100x like in PoS, because only the token appreciates, while the mining gear depreciates.
See the difference?
There's good research on the subject: https://download.wpsoftware.net/bitcoin/pos.pdf
But why do we need PoW at all?
Problem is, in digital world, anything can be simulated. If we're trying to simulate gold, what's to stop us to change the color of this 'virtual gold'. If we can do it, then why it should have value? The most important property of a cryptocurrency is ensuring certainty of its properties, like emission, fungibility, immutability, security etc. We often hear the term 'voting' but I think it is misleading. When you vote, it's someone else performing some action. This is not the case with cryptocurrency. When you 'vote', you're really only saying "the crypto with xyz properties is the one I consider valid" and if someone sends you something with xyq properties, you ignore it as invalid. If there are many peers stating exactly the same xyz properties, then it becomes a currency among them, and anyone accepting xyz as properties is free to join and transact. The more peers accepting it, the more certain you are you will have peers to transact with who're accepting the xyz properties. So where's the vote making someone else do something? There's no such vote. You either accept xyz or you don't. That's the role of nodes. There's one property which the nodes simply aren't able to verify - chronological ordering of transactions and for that, we need miners. That's it.
With PoW, any attempt at rewriting history is expensive. With PoS, it's free. 'Solutions' to make PoS 'work' like checkpoints defeat the purpose because how can you tell which checkpoints are the 'right' ones? Someone said so? Some 'trusted' server? I thought we're building trustless decentralized systems here :)

Part of your issue with pure pos system with no checkpoints and full premine is that the fund holder of all the coins or tokens has nothing at stake to loose.  This is fine when there is no value in the coin but as soon as there is value the incentive to double spend and cash out on your large holding while being able to double spend becomes too much that it will be done.  Nubits ran into this problem with the need for 51% or more on votes to pass motions on buy backs on the coin being approved by the same 51% stake in the coin holders.  No one has a pure pos system that works, peercoin is due to remove the centralized checkpointing in the next version 0.6 and I have not seen any other pos coin achieve the necessary distribution to be confident the network will not be at risk by removing the checkpointing.
Any pure pos system one has to ask about distribution methods and how the market value has been determined, has it been through true market fluctuations over time or has it been inflated by a few holding coins off the market just to push the price high?
Trust has to be earnt, by a premine and central authority how has any trust been earnt to invest in the cryptocoin?

If you have a central authority, why do you need a consensus algorithm like PoS at all? Just have the central authority sign all the blocks, and let nodes reject blocks without valid signature.


text:
I tried to withdraw coins from Binance but they were lost on the blockchain. I need help from an expert
I really need some help from someone with a lot of knowledge and experience with crypto trading.
I tried to withdraw LTC from my Binance account recently, but I mistakenly used a BTC "receive address" from my Green Address desktop wallet, and the transaction didn't go through. I've contacted Binance and Green Address customer support several times and neither company is willing to help me recover my lost coins. Binance won't own the fact that they allowed a transfer that had an invalid receive address (the address started with a "3", not an "L"), and they said my coins are now lost on the blockchain.
Green Address says they don't have access to my private keys in order to help. I don't know how to access my private keys or even if they exist. I do have 2-factor authentication enabled on Green Address wallet. I've been told by members of this forum that I may be able to recover my coins if I'm able to convert my Green Address wallet to a cold wallet, and I have emailed Green Address with that question and am waiting for their reply.
Someone also posted that I try calculating an address from my wallet seed. I have no idea how to go about doing that and that's one of the things I need help with. I'm a total newbie to crypto trading and trying to understand all the technical steps is overwhelming and hard to comprehend.

I would be eternally grateful, if someone would be willing to walk me through the steps of how to recover my LTC coins?
It's a lot of money to me. I'm attaching a screenshot of the original transaction from Binance website, including the Green receive address and the Txid.

transfer that had an invalid receive address (the address started with a "3", not an "L")

An address starting with 3 is a valid LTC address, so Binance could not have known this is not where you want them sent.
In your particular case, recovery may not be possible without cooperation from Green Address. Green Addresses are 2of2 or 20f3 multisig addresses and require two keys to spend coins from. One key is from your seed words, and the other is held by Green Address, in the case of 2of2.
Unless you are able to convince Green Address to share that key with you, or sign a tx using it that moves your LTC, you will not be able to access the coins.
If you have a 2of3 multisig, you hold 2 of the keys, and should be able to use an Electrum-LTC client to generate the multisig address and use it on the Litecoin chain.

GreenAddress wallets are either 2-of-2 or 2-of-3. In the latter case, it is possible to recover (in theory) without GA's help.

Right, forgot they offer the 2of3 as well. I've updated the answer, thank you!

Is there a private key associated with the wallet address you sent to by mistake?
If you can obtain the private key, there is hope. If not, then I’m sorry to say all may be lost.

Just dispute it from your bank. It’s not your fault that binance allowed it to go through. Or, it they can allow it to go through why can’t they reversed it somehow? Binance should have more security. It’s a lot of money on stake, and the only thing that I can see as a solution right now is to dispute all the money that you use to buy your coins. If binance can’t help you then you have to do it your own way. It’s the law you authorized the transaction, but you did not yet the value that you purchased.

Welcome to Bitcoin.SE! please remember that we have a be nice model.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Bitcoin cash faucet
Is there any other bitcoin cash faucet instead of this
I'm facing the same problem as this question.

are you looking for BCH faucet or some BCH-testnet coins?

I believe OP looking for BCH-testnet coins.

I am looking for working 'BCH faucet', wanna test my BCH wallet web hook (test.bitgo.com).

You can try this site for getting Testnet coins:
https://testnet.coinfaucet.eu/en/

Bitcoin "Cash"...

I am NOT looking for bitcoin faucet. I am looking for BCH ->  bitcoin cash faucet

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does Proof-of-Stake works programmatically
I've researched on the internet, but am still confused about how Proof-of-stack works programmatically.
As mentioned here, in Proof-of-Stake system, A random Nextcoin is selected to be the next "miner". Which node is designated to randomly select a node as the next "miner"? Or in other words, how can a system agree on a random number in a way that can't be manipulated?

In most proof of stake systems, there isn't really some node that says "this node is the next staker". Rather what many do is, using data from the blockchain, calculate a set of public keys (the set can just be one public key) that can be the next staker. If a node that has the private key for one of those public keys is online, they can construct the next block.
The way that the set of public keys is determined varies by coin, but they all use data from the blockchain and a deterministic algorithm so that all nodes will come to the same set of public keys.
The randomness in these algorithms typically comes from hashing data which could not have been known beforehand (e.g. for block n, take the hash of block n-1). In this way, a random number is generated such that all nodes on the network will generate the same number.

Is this correct: all the nodes shares the same algorithm to generate the public keys from the blockchain. Then after block n-1 is generated, all the nodes shares another algorithm so that they will agrees on a public key to determine the miner for block n.

They don't share anything, they use the same algorithm, so given the same blockchain, they will calculate the same thing and thus agree on the public keys. But yes, your idea is correct.


text:
How to transfer private addresses from one wallet to another?
My wallet has 3 addresses. My other wallet has 5 addresses. I just want to synchronize those.
How would I do so?

Just export the private key of one wallet and import to the other.

the export is in a plain text file. Is it safe?

@hyh this would be a better answer if you explained the export and import process in more detail

see http://bitcoin.stackexchange.com/questions/23909/import-private-key-on-multiple-computers/23911#23911

Please explain why you want to do this?
If your goal is to consolidate the funds, just send the money from one wallet to the other.

The 2 wallets share 1 private addresses (and a bunch of other addresses they don't share.)

Again, please explain why.  If your goal is to consolidate, send all the funds from each wallet to a third wallet.

Sending the funds would incur a fee which seems undesirable for a bit of housekeeping.

How to clone BitCoin Addresses between different Wallets. Case: BitCoinCore <> Electrum
This informal article is not about transferring funds between wallets, nor about using the 'sweep address' procedure to transfer funds from one address to another.
It is about cloning an address from one wallet into another different wallet. This address will be usable from both.
Wallets are sets of Addresses. Each Address has a balance ('amount') an id ('address'), a tag ('account'), and a private key.
In order to clone addresses between wallets you have to know the private key of source address.
BitCoin Core  ==> Electrum
BitCoinCore:
Help | Debug Window | Console
backupwallet "local file system destination\wallet.dat"     # make a backup copy of your wallet (optional)
dumpwallet  "local file system destination\wallet.dat.txt"  # make a human readable list of your wallet.  Warning: includes private keys so destroy after use

Electrum:
Wallet | Private Keys | Import | copy here the private keys of address(es) to be cloned see file wallet.dat.txt

Electrum ==> BitCoin Core
Electrum:
Wallet | Private Keys | Export
save or copy paste to the notepad, warning: keys are prefixed with 'p2pkh:' you must ignore that prefix. Warning: includes private keys so destroy after use

BitCoinCore:
Help | Debug Window | Console
importprivkey "private_key from above" "optional_tag"
    warning: After that BitCoin Core automatically rescans the whole database, this may take hours.
backupwallet "local file system destination\wallet.dat"     # make a backup copy of your wallet (optional)


text:
Why is Enjoy Sochi a malicious spam attack
I recently read the following thing on reddit:

The two transactions for .00000001 BTC are a malicious spam attack.
  They were sent without fees, which means that if you wallet doesn't
  allow you to choose specific outputs your balance is tied up until
  those transactions confirm.

Surely this is a spam (although I can not understand what is advertised), but I can not understand how is it a malicious attack. What exactly can be achieved by this attack?

Note the comments on that thread "OP is a known troll and the attack doesn't exist."

Thanks, but I do not really know whether to trust this comment or no. My opinion if it is known that he is a troll, why not to ban him?

Ran into this myself

The transactions will likely never be included in a block, as they do not meet the defacto bitcoin transactions rules for transactions sent without a fee, detailed here:

A transaction may be safely sent without fees if these conditions are
  met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
*Copied from https://en.bitcoin.it/wiki/Transaction_fees#Sending*

Since the transactions fail to meet the criteria to be included in a block for free (which is already getting rare), the transaction will likely be rejected on most/all mining pools, though may be rebroadcast by the sender or the receiver. The transactions may remain unconfirmed for a long time, unless the sender double spends his inputs, nullifying the transactions.
The attack is similar to a ddos on the bitcoin network, as the transactions propagate through the nodes which accept and relay the transactions. This does not cause issues with the '7 transactions per second rule' as the transactions will likely not get into a block, but may cause latency if enough of these transactions are broadcast.
It's more of a pester than a malicious attack.

A transaction can be submitted (and resubmitted) via any node running bitcoin, so long as the transactions are valid and signed by the owner of those coins.

I got them appearing (unconfirmed) in my Blochchain wallet again today. I assume it is something to do with the database repair.


text:
Can Litecoin mining be bottle-necked by motherboard/cpu?
So I brought 2x Sapphire Vapore-X R9 280X video card.  I am only doing 550kh/s each while on my other more powerful setup with the same card get about 750kh/s.  I am wondering if the motherboard/cpu matters?  Here is what I got on my new rig:
Asus P5K
Intel Core 2 Duo @ 2.66Ghz
2GB DDR2 Memory
As far as my research goes, this should all be fine, but at the end, the hash rate does not lie, what am I doing wrong?

are they all running the same configuration file? if so can you share the configs you are using?

I highly doubt it. Even the PCI-e connectors do not really matter. I've got less CPU power and RAM than you and my rig is controlling 4x 7950s at full potential. The CPU/Motherboard is essentially calling functions. The functions themselves are what cost so much, and those are computed by the GPUs.

That is so weird then... thanks for the insight though.

I Have seen comments that having less ram on your motherboard than in one of your GPUs can significantly reduce the hash rate. If your only running 2GB ram, but your cards have 3, so try 4GB ram on your mobo and see if that makes a diference

Looks like those GPUs each have 3 GB of ram does OP need to match and be running with 6 GB RAM for optimal performance?

I'll buy 2 more GB, RAM is cheap.  But I don't know how much difference it will make.

Only GPU matters. In the link you can see R9 series performance charts for LTC mining
http://www.youtube.com/watch?v=m_0j5ntR4w0

Wow, that's kind of impressive to overclock the 280x to about 980kh/h.  To bad it doesn't say how that's done.

From what i've gathered, the comments on matching system RAM only apply when your using Reaper as mining software. The likes of cgminer runs quite happily with only 2GB in system and 4 x 7950 3GB cards.

Make sure you are using TWO gpu threads, this is often the cause of underperforming 7950/7970/R9 280x


text:
Can I mine with BFGMiner on an ATI Radeon
I have managed to connect to the pool via the command line but when I went to manage devices it says I have none. I tried to use auto and all commands to add the GPU and seemingly it will not pick it up.
Is it even possible to use a amd m880g?
Any advice appriciated
EDIT
I have also found the same is true with cgminer. Is it impossible to use this card?

You need to use cgminer-3.7.2 or earlier.  For some reason, GPU mining was removed from subsequent versions.
Cgminer is the best available miner for your purposes.  Con Kolivas is one of the world's great programmers, and we are lucky to be able to use his software.
Please also be sure to read the file SCRYPT-README to get reasonable performance.

I've tried 3.7.2 and it still doesn't find my card either.  Is there something special we need to do?

Actually, this question is even better than your original question, as this is a notoriously difficult point.  The answer is yes,  you need to do a lot of things in this case.
The first thing to do is to download the source code and attempt to build it by following the instructions.  When you configure it,  the software will show you what is missing.  There are a lot of libraries that must be correctly installed, and cgminer will tell you what you have failed to do.
Some people also claim that only certain ati drivers work, but I haven't had that problem.

Sure you can if you want to waste energy and time. You should buy specialized hardware, Butterfly labs or Kncminer are two company releasing ASIC miners. Alternatively you can try with cloud mining with cexio. You can buy and sell GH/s with bitcoins. Receive mining rewards and make a profit on trading. Fees are low as well, only 0.0001 when you will withdraw from the account.


text:
What part of the transaction is scriptSig in?
I was reading this paper
https://web.archive.org/web/20140331191527/http://bitcoinhistory.net/Technical_Papers/ProgrammingBitcoinTransactionScripts.pdf
and I have the following question:
ScriptPubKey accompanies a transaction output and specifies under which conditions it can be claimed. ScriptSig accompanies a transaction input and is used to prove that the referenced output can be rightfully claimed.
So in page 2 the ScriptSig should be in Input TX and ScriptPubKey should be in output TX? Author says that scriptA is ScriptSig.

the link you posted is dead, at least for me

Here's a mirror.

I was confused by that too. Here's the picture with some more labels on it.


text:
How do I scan my bitcoin receipt into my wallet?
I bought Bitcoins from the Robocoin ATM (I'm told it's the only one) and it gave me a receipt with a QR code to scan into my wallet. I downloaded Blockchain, but don't see where in the app I can scan the receipt to add to my wallet. Help!

What does "I downloaded blockchain" mean? What program are you using exactly?

Using the blockchain.info app go to your address book (menu button in top left).. then when in the address book click the same top-left menu button and you'll see the import private key option. Scan the QR, job done.
Alternatively use a QR scanning app such as QRDroid and then you can copy & paste the resulting private key into anything you like.

Find a button labeled "import private key", and it'll open a camera view to let you scan the QR code.

Thanks for the quick response. I'm not seeing that button. There are 4 tabs on the bottom. On the piggyback one the screen just says "No Data". Refreshing does nothing.


text:
BIP-0016 p2sh keys and altcoins
It appears that bitcoin addresses using p2sh keys have a different prefix to that of normal bitcoin addresses. Do other altcoins such as litecoin, peercoin, dogecoin etc include this functionality?

Most likely, they are 1:1 clones most of the time of BTC.

Upon looking at the source of a number of altcoins I have found that p2sh keys are built into all the ones I checked.
For P2SH, the first address byte will be:

bitcoin: '05'
  litecoin: '05'
  peercoin: '75'
  dogecoin: '16'
  beavercoin: '05'
  freicoin: '05'
  protoshares: '05'
  megacoin: '05'
  primecoin: '53'
  auroracoin: '05'

The tricky bit about this is that you can't nessesarily tell what network a P2SH address belongs to like you can with normal addresses.
The reason I wanted to know is so I could collate the version numbers for my project:
http://github.com/ryanralph/altcoin-address


text:
What is the benefit of using a Merkle Root rather than simply hashing all of the transactions in the block?
I understand what the merkle root is and how it is calculated, but I have not been able to figure out what is the actual purpose behind using this kind of hashing solution?
I mean, I know that the root itself must be there, to identify the exact block's payload, but what I don't get is why didn't he just choose to calculate the hash using a normal double SHA256 over the entire block's transactions? Why did he come out with this tree-idea instead?
I do not see the tree based hashing to be adding any security, neither to have any useful advantages over a regular (linear) hash... so am I missing something?

The Merkle tree allows verifying that a transaction exists in the block without having the entire block, by following its Merkle branch. Among other things this enables:

SPV (lightweight) clients
Blockchain pruning
Smart pool miners

What are "blockchain pruning" and "smart pool miners"?

@Pacerier: Pruning means deleting old spent transactions from the blockchain. Smart miners means that the miner constructs the block himself, and sends the pool the Merkle branch of the generation transaction to prove that it credits the pool.

To see how it simplifies verification, consider that in order to verify a transaction T is part of the blockchain, the verifier has to get from the transaction hash to the merkle root. If there are n transaction, there are log_2(n) levels to climb in the merkle tree, so to speak. To climb from the transaction T's hash to its parent P, we only need its sibling, since that is how the tree is built. Then to climb the next level we only need the sibling of the parent we calculated P, and so forth.
To climb all log_2(n) levels of the tree we only need T's hash plus log_2(n) extra hashes (including the merkle root). If we did a linear concatenation of blocks, we would need much more information than log_2(n) << n
I found this article helpful for illustration:
https://en.bitcoin.it/wiki/Merged_mining_specification#Merkle_Branch
Hope this helps

This is the answer that really explains the question – why Merkle root vs straight hash.

I believe it's to enable Simplified Payment Verification (SPV).  A client who doesn't wish to download the full blockchain can still verify that a transaction exists in the blockchain by confirming that the block headers are linked, and validating the relevant parts of the merkel tree to confirm the transaction really exists in the block.


text:
Sending coins from Multibit stuck at "Unconfirmed / Pending"
I bought some bitcoin in 2013 and stored it in my Multibit wallet (0.5.16). I am trying to convert my bitcoin into USD.
First, I found that I was running an old version of Multibit, so I attempted to upgrade to MultibitHD as instructed here. I sent a small amount of bitcoin (0.0001) to the MultibitHD wallet, which remained unconfirmed / pending, with no record on blockexplorer.
My understanding, which please correct me if I'm wrong, is that since I'm sending the bitcoin, there's no difference between sending them to a new wallet provided by MultibitHD, and say a Coinbase wallet. So, since I want to sell these things, I figured I'd try cutting out the middleman and sending directly to Coinbase.
I upgraded Multibit Classic to 0.5.19, and then sent 0.0001 bitcoin to my Coinbase wallet, and it appeared (pending) in Coinbase. Great, so I then sent the rest of my bitcoin, only to see a "square" in Multibit Classic, no record on blockexplorer, and just unconfirmed / pending.
Freaking out a bit, I looked over this answer, and this Multibit FAQ and surmised that, since Multibit Classic automatically calculates the fee (I believe it was 0.0001 BTC, or around $0.10) it must be a network issue. I then did a "Reset blockchain and transactions", and when that completed my transactions were cleared of the unconfirmed transactions, but my wallet balance was at 0.
Luckily, I had a backup. I booted that sucker up and my bitcoin balance was back to where it was, synchronized with the network, with no record of those transactions (also no record of the Coinbase transaction, which is confusing). I upgraded Multibit Classic to the latest release, 0.5.19, and sent 0.0001 bitcoin to MultibitHD. It appeared successfully. I then sent another 0.0001. This gave me (another) square with unconfirmed / pending.
I'm now sort of at a loss as to what to do, and feel like I'm playing with fire without a strong understanding of what's going on.
To recap:
I want to convert my bitcoin from a Multibit Classic wallet into USD.

I sent 0.0001 BTC from Multibit 0.5.16 to Multibit Classic, was
stuck in unconfirmed / pending state
I sent 0.0001 BTC to Coinbase, then the rest of my BTC. First transaction worked, second stuck in unconfirmed / pending state.
I sent 0.0001 BTC from Multibit Classic to MultibitHD, twice. First transaction worked, second stuck in unconfirmed / pending state.

My best guess is that the fee I'm paying is not high enough; but there seems to be no way to set the fee in Multibit Classic. I would gratefully appreciate any help as to what I'm doing wrong here.

Just to update this - I tried again the following day, in slowly rising increments, and this time the transaction went through. Not sure what happened before, but for others that stumble upon this, maybe... try again the following day? Or maybe someone else has more information to provide.

I am having the same exact issue. It would be nice to have some closure. Thanks everyone!


text:
Can it be mathematically proven that a block can be solved?
In other words, that there exists a nonce for the block that will result in sha256(sha256(block header + nonce)) hash under the current difficulty barrier number.

It would be better, if we could relate block n, in terms of f(block n-1).

I agree with some of the comments in the answers that this question is poorly worded. I'm going to submit an edit to what I think he means "how do we know that a block as a valid answer?", but that will essentially be a dup of "http://bitcoin.stackexchange.com/questions/9933/is-it-possible-for-the-network-to-stop-finding-valid-blocks" so I will submit a dup close as well.

On second thought, this might not be a true duplicate, so I'll just post an answer that covers the gaps between this question (at least with my pending edits) and that one.

The clients make use of the Target to determine if a block hash is valid and will be accepted by the network. The Bitcoin wiki states the following:

The target is a 256-bit number (extremely large) that all Bitcoin
clients share. The SHA-256 hash of a block's header must be lower than
or equal to the current target for the block to be accepted by the
network. The lower the target, the more difficult it is to generate a
block. [...]
Each hash basically gives you a random number between 0 and the
maximum value of a 256-bit number (which is huge). If your hash is
below the target, then you win. If not, you increment the nonce
(completely changing the hash) and try again.

The current target value can be found here: http://blockexplorer.com/q/hextarget

Well, I am asking for mathematical formula that determines the existence of N valid blocks. That miners can find.

Then ask a question in understandable English.

No, there is no way of proving that a hash exists other than actually finding that hash. (i.e. brute force). The existence of a method of being able to predict the result of a hash other than computing the hash would render the hash function cryptographically unsound. (And so we can infer that no mathematician has found such a method for SHA-256).
That said, as discussed in this other Q&A, there are a number of characteristics of a block that are dynamic so it isn't as if an "insolvable" block would actually cause any network problems.

do it implies? If sha256 has a unknown flaw, with non "random" data, block can not be solved with current "difficulty"?
number of nonces per "diff space" vs expected probability results?

I am sorry, but I can't understand your English. But I think what you are asking is answered in the other question I linked to. Remember that a block isn't particularly "fixed". The coin base, the transactions, the order of the transactions, the timestamp: these all can change. Even if you could craft a block that is insolvable by using an unknown vulnerability in SHA-256 (and that's a huge if), changing any of those other inputs would result in a different (solvable) block.


text:
Is it possible that the authors of Bitcoin have an alternative way of generating bitcoins?
Is it possible that the Bitcoin creator (or developers) have an algorithm that allows computers to generate coins easily, but intentionally published only the current difficult mining algorithms. And, in that way, have left themselves a backdoor way of generating bitcoins once the algorithm became popular?

Your question is equivalent to asking, "Does SHA256d have a trapdoor?"
SHA256d is a well studied algorithm.  It's believed not to have a trapdoor.
If the creator of bitcoin has a way to break SHA256d, stealing all our bitcoins would be the least of our worries.

Basically, yes. But it doesn't have any dramatic effect and it's almost certainly over by now.
When Bitcoin was first released, it was not generally known that it was possible to mine efficiently using GPUs (video cards). It's possible that the Bitcoin creators and early developers knew this and withheld the information, giving them a tremendous mining advantage if Bitcoins had gone up in value before this was discovered by the general public.
Note that you can't mine "more" Bitcoins in total this way. Bitcoin's core mechanisms limit the total number of Bitcoins that will ever exist to a bit less than 21 million. But you get a much greater share of the Bitcoins mined than you would otherwise be entitled to.
Since the announcement of Bitcoin and since the value has gone up, the mining algorithms have been very well studied. Any such creator advantage would long have dissipated now. Bitcoin didn't pick an algorithm that's fundamentally new, the difficulty of mining is based on the number of SHA256 hashes you have to do and it's almost inconceivable that there would be any faster way of mining other than figuring out how to do these hashes as quickly as possible.
There's no secret backdoor. There's simply no place to hide one. But it's possible the developers had a head start on figuring out how to execute the mining algorithm quickly. Again, that's long since dissipated. The mining community in general has now had a massive resource advantage over anything the original creators and early developers could have mustered. They wouldn't have invested millions into the fastest way to mine because that would have been an insane risk before they knew Bitcoin would even catch on or that the mining algorithm would remain the same.


text:
Get transaction that spent a transaction id
The blockchain.info API allows for querying information about a particular Transaction by its ID. But if you want to follow the coins to the next transaction, I'm not seeing what the next query should be.
Each "out" of the transaction has an address associated with it, and you can query for details about a address' recent transactions. But if you're exploring deep in the past, the most recent 50 transactions for a given address won't have the spend for that particular "out".
So is there another API out there that allows you to query Transaction details based on "has transaction N as an 'in'"? Or do I need to go through the blockchain and make my own cache?
Edit: Blockchain.info clearly has the link to the transaction that spends a given output in their database, since the HTML view of a transaction now has "spent" tags after outputs that have been spent, which are links to the next transaction. However, that particular bit of data is not in the API view of the same transaction.

The raw transaction info includes the Unspent Transaction Out (UTXO) which is the link to each of the components of the spend:

http://blockchain.info/rawtx/$tx_index

I'm not looking for the unspent ones, I'm looking for the spent ones. And either way, I'm not seeing a "utxo" field in the raw transaction output; for example, TX 68491522 has two spent outputs, and you can click "spent" next to each in the HTML version to see the next in the chain. However, looking at the raw version, that data doesn't have any links like you're describing that I can see.

Ancient question but it is still relevant today...
With many blockchain APIs, there is unfortunately no way to query "which transaction spent this output?".
The most efficient alternative is to download all transaction history for the output address, and parse every transaction, looking for one that spends the output in question.

You have to go through the blockchain and create your own cache. I don't know of any service available that allows you to run a query like this on their API. Too many people use blockchain.info anyway, so it would be valuable to have other entities providing their data to the network.


text:
Why is bitcoin better than other electronic banking, like Dwolla or Paypal?
Why is bitcoin better than Dwolla or Paypal?

http://bitcoinmedia.com/bulleted-advantages/

possible duplicate of What is Bitcoin?

You don't need anyone's permission to use it. Nobody can freeze your account or charge back a payment after you received it. It's accessible to anyone with Internet access regardless of what country they're in. No single company can dictate its policy. It is almost free to use with no proportional fees.


text:
Strategies against Bitcoin
With the recent increase in articles about the threat of Bitcoin vs central banks, government and other authorities over the money supply, I am wondering how well authorities are prepared and actively dealing with the situation.
Yes, most are probably aware of it by now. There have been some official statements by several agencies. Most notable I could find are the ECB: Virtual Currency Schemes (PDF, European Central Bank - October 2012), U.S. Senators seek crackdown on "Bitcoin" currency (Reuters, June 2011) and FBI Fears Bitcoin’s Popularity with Criminals (Wired, May 2012)
Is there any proof that serious plans are in the works to 'crackdown on Bitcoin' - either directly by creating laws or indirectly by influence on the market?

AFAIK, no: they are aware, and aren't acting.

As total net worth of Bitcoin is around $200 million, it is not a threat yet.

just some ideas:
Strategies could be attacking the trust structure of bitcoin:

Buying large quantities of bitcoins and dropping them on the market causes it value to fluctuate and make it appear weak
hacking peer sites (like mtgox), or bitcoin users directly (via trojans, etc.) leaves insecurities on where to use it
influencing media to emphasize about the dangers of bitcoin (selling drugs, weapons, etc.) will make it less accepted in society by creating fear
creating various alternative currencies, flooding a lot of misleading information, to weaken the marketing of bitcoin by confusion and information overflow

Could be attacking the technical side:

Creating big amounts of powerful ASICS and use them for false verifications
stuffing the blockchain with spam information and useless transaction, making it to big to handle
Blocking and filtering traffic from bitcoin clients, will make it necessary to use TOR (which could be also blocked in certain ways) and will render bitcoin unusable for the average person
Switching of the internet
Brute Force attacks on the network to render it slow and unusable

Could be attacking it by legal means:

Making it illegal to use bitcoin, and tracking users via ISPs, a few show trials and people won't want to use bitcoin again (so TOR could be again an option to circumvent)
shutting down and making peer sites illegal (if they are not already, e.g. mtgox, silkroad)

Great leverage for Bitcoin will eventually come by using it via smartphones and alike, bringing the currency to the street markets. If they find a way to block these trades, they will also hurt bitcoin a lot.

In the U.S. FinCEN changed the term used for prepaid cards from "stored value" to "prepaid access" and refers to "electronic codes" as being one of the types of "prepaid access".  Additionally, they have widened the scope of what a money service business is, and that new scope includes those that serve U.S. customers online even without having any presence in the U.S.

http://www.bitcoinmoney.com/post/11074108719


text:
Is there a reason why miners should respect the default maximum block size?
Actually the default maximum block size is 300,000 Bytes and the protocol hard limit is 1MB.
So what I understood is that all blocks over 1MB will be rejected but the ones between 300,000 Bytes and 1MB will not.
So if there are lot of transactions with little fees that make that a miner can create let's say a 700,000 Bytes bloc. Will it be profitable for the miner to create such a block or is there a additional risk that his block will be rejected?

You should know that as of bitcoin 0.8.6, the default maximum block size is actually now increased to 350,000 bytes.
The 350,000 bytes is a soft limit. All miners are motivated to maximize filling the block size to 1MB for each block because it would be irrational for them to do any less and leave fees to other miners that they could easily collect themselves.
Thus all blocks are usually mined to the maximum limit with paid transactions and then free transactions are included once all fee-based, unverified transactions have been verified.

If there are a lot of transaction with fees the miners will create 1MB blocks and the rule only apply for free transactions?

authors: Виталий Лошкарев


text:
Is IQmining worth the investment?
I am interested in investing in crypto-contracts, is IQmining worth the investment?

Pretty much any mining operation short of buying hardware (ASICs, GPUs) is a scam.
IQ Mining appears to be a ponzi scheme of some form based on a quick Google.


text:
Converting Litecoin M-addresses to a more commonly accepted format
Is there any way to convert an (LTC) M prefix address to an L prefix address?
Many services an apps that accept and transfer LTC reject M-addresses as invalid, even though they are given out by Coinbase.
I called Coinbase support but was unable to find a solution.

Does this answer your question? convert "M" address to "3" address LTC

You cannot convert an M prefix to an L prefix as they are different types of addresses, the first being a P2SH address and the latter a P2PKH address.
You can, however, convert it to a 3 prefix address using https://litecoin-project.github.io/p2sh-convert/, a convertor built by the Litecoin Foundation for this exact purpose.
Originally, Litecoin used the 3 prefix for their P2SH addresses. However, this caused an overlap with Bitcoin, which also uses a 3 prefix, and led to many people sending funds to incorrect addreses. Litecoin then changed their prefix, but since it is simply an encoding change, you can convert it back to the original prefix for wallets that have not yet update their integration to respect the new prefix.


text:
Transaction records?
Can you track your payment if you do a transaction from person to person for a house rental if the seller doesn't follow through with their end of the deal and doesn't send the keys can you get your money back?
Or in other words is there a record of your transaction so you can claim a dispute or track down the person who didn't follow through?
What safety do i have in this aspect for example i am applying for  rental house but i found out they're in the states and I'm in Canada so they have to send me they keys but they want the payment first through btc wallet so if i do this and send the bitcoins and he doesn't send me the keys and i find out it was a scam is there a way for me to recover my payment?

You have no safety. If the seller doesn't follow through, your money is gone forever. no-one can get it back for you. There is no way to recover payment. There is no way to identify or trace the seller.

Can you track your payment if you do a transaction from person to person for a house rental if the seller doesn't follow through with their end of the deal and doesn't send the keys can you get your money back?

You can view your transaction's status on a block explorer or your own node, if yu have one. You cannot get the money back unless the other party explicitly sends it back to you in a new transaction. Bitcoin transactions are irreversible once confirmed.

Or in other words is there a record of your transaction so you can claim a dispute or track down the person who didn't follow through?

Bitcoin is a decentralized system. There is no one to file a dispute with.

What safety do i have in this aspect for example i am applying for rental house but i found out they're in the states and I'm in Canada so they have to send me they keys but they want the payment first through btc wallet so if i do this and send the bitcoins and he doesn't send me the keys and i find out it was a scam is there a way for me to recover my payment?

Usually, for such transactions, you would utilize an escrow service that only releases the BTC to the seller after you have received what you paid for. You should ask the seller to use a reputable BTC escrow (there are a few on Bitcointalk). If the seller refuses, you should proceed with caution, if at all, as many people are scammed by such offers.


text:
BIP39 12 words combination list
From where I can get bip39 (2048 words) 12 words length possible combinations.
Note: I am not talking about the wordslist of bip39 (2048 words).

From where I can get bip39 ( 2048 words ) 12 words length possible combinations .

There is no such list, because it is simply too large.
From the 2048 words, 12 word mnemonics are 11 words + 1 checksum word. However, the checksum calculation only affects part of the 12th word, so you are still looking at 12 word combinations
This gives you 2048^12, or 5.44451787e39. That is a 40 digit long number. Even if you were able to calculate 1 billion combinations per second, it would take you
1.726*10^24 years to calculate all combinations, or around 1.3 * 10^14 times the current age of the universe.
Of course, adding in the checksum validation would reduce the list size very slightly, but it would still take you several times the age of the universe to generate that list.


text:
Benefits of generate address from sha256 hash than random address
Is there any benefits (eg: better security) of generate a address from SHA 256 hash vs generate a random hash?
Generate adress from a SHA 256 hash
var value = Buffer.from('correct horse battery staple');
var hash = bitcore.crypto.Hash.sha256(value);
var bn = bitcore.crypto.BN.fromBuffer(hash);

var address = new bitcore.PrivateKey(bn).toAddress();

Generate a random address
var privateKey = new bitcore.PrivateKey();

var address = privateKey.toAddress();

Generating from the hash of a string is known as a Brainwallet. This has the advantage that it is potentially easier to remember and recreate your wallet if you lose the keys.
This also have the disadvantage that people are terrible at picking entropy, and it is trivial to crack most brainwallets via brute force. You have far more security relying on randomized generator than more or less any brainwallet you could come up with.


text:
Gear/approach to legimitately mining (not buying) a single Bitcoin
Background
I have a relative who has been trying to get into Bitcoin mining. He accidentally installed malware onto his home PC twice, thinking it was a mining tool. He understands mathematics but is not well versed with modern technology, PCs, etc.
Question
What sort of hardware/software/etc would I purchase if I want to have a standalone device sitting (quietly) in the corner of my office that would have a reasonable expectation (95%+ CI) of earning a single coin within, ideally, 6 months? The power/hydro bill isn't a problem, as I'll be paying it. It's to my understanding that I need to consider ASIC/FPGA-based boards to be remotely competitive.
Goal
My goal is to pre-mine a single coin, give him the box as a birthday present, and have a cron job add the coin to his wallet at a set date. I think it'd make his day (day he always felt lucky).
Additional info
How do I help him legitimately cash-out his single bitcoin, so that the bulk of the face-value is cashed out, and he has a receipt he can file properly at tax time?

You can pre-mine a block, but that might become invalid if you sit on it too long.

@jiggunjer what? How do you 'pre-mine a block'?

@meshcollider I'm not sure, I just figured it would be theoretically possible. You just need to not broadcast it when finished?

@MeshCollider After looking through this more thoroughly, your assertion sounds correct. If you convert that comment to an answer, I'll mark it "accepted". Thanks.

@jiggunjer mining is a race, if you didn't broadcast it when finished you'd be wasting your time completely and would get nothing because someone else would find a block and yours wouldnt make it into the chain

At current difficulty, you aren't going to be able to mine an entire bitcoin in 6 months with even the Antminer S9 ($3000 each), you'd probably need two of them, are you sure you don't want to just buy 1 BTC and a cheaper miner for the show?

The days of individuals having a decent probability of solo mining bitcoin are long gone because of reasons mentioned by the first two answers.  Yet bitcoin prevails as the crypto currency 90% of people initially encounter when delving into digital currency.  So many still consider mining bitcoin, almost pointlessly, and that’s the lifeblood of btc mining hardware companies who are selling hardware which is guaranteed to be worth about 0.25% of what you pay for it 12 months later.
An alternate suggestion for anyone new to mining, is mine Proof-of-work crypto currencies where you actually have a chance of buying a handful of gpus and catching a block every now and then.  Without massive investment this is highly unlikely with bitcoin

Bitcoins aren't mined individually; they're awarded to miners who discover a block.  This process is like a race that restarts every ten minutes when a new block is mined (the miner gets a block reward plus transaction fees).
In order to have a shot at winning these races, mining operations use expensive arrays of custom hardware.  So, without that, you would have a pretty slim chance of discovering a block before one of them did.

This answer ignores mining pools completely. Of course you'd use a pool.

authors: Олександр Нестройний


text:
Where to find help understanding Bitcoin's source code in C++?
I am looking to understand the Bitcoin C++ source code on GitHub. The Python one is simpler, but even that is too complicated for a beginner. Could someone guide me to some good resources on the actual implementation and its details? The actual C++ techniques used seem to be quite complicated.

I answered this question here. Do check. Also, I have written a blog on this topic, might help you.

I am not aware of an extensively commented version of the Bitcoin sourcecode, but you could check out the Bitcoin Developer Reference and you can read online the book Mastering Bitcoin by Andreas M. Antonopoulos, which covers Bitcoin's technical aspects extensively. There is also Princeton's Free Online Bitcoin course, which goes into details on some technical aspects, which might in turn help you understand the sourcecode better.
Besides that, try searching Bitcoin.SE for specific questions, there are a few here that have been asked about already, if you can't find something, feel free to ask a new question here.

Thank you. I am reasonably comfortable with the theoretical aspects. I am looking for pure implementation details like critical sections and libraries used and such..

It is probably the easiest if you then ask specific questions about any sections of the sourcecode you want to understand better. Alternatively, you might want to try asking advice in #bitcoin-dev on freenode, where a lot of Bitcoin contributors hang out regularly.

My new book "A Dissection of Bitcoin" examines the original Bitcoin source code written by Satoshi.
As for now, it is the first and only book available that helps you read the Bitcoin source code.

I've seen the book for sale online but it appears to be only four chapters. (iTunes: "The whole book has 10 chapters. This version you are about to purchase contains the first 4 chapters.") --- Where can I get the full 10-chapter version?

Never mind, found the full version here.

Can you please release new book version for 2018? I want to buy cause i am working on 2018 but your book is very very very very old.

@paul-huang, can I still purchase the full version?

The Bitcoin codebase is a very large today, with roughly 370,000 lines of code in the 0.17.0 release.
There is a Github project that help developers read open source projects. Check out the entry on Bitcoin:
https://github.com/CodeReaderMe/awesome-code-reading/issues/2.
It contains an overview of the Bitcoin codebase as well as some tips to get you started.

Aside from what @Murch♦ mentioned above (especially the developer reference), a good source for this is the Doxygen documentation. You can generate it locally or it seems to be published here:
Bitcoin: Developer documentation
Unfortunately the documentation itself is pretty sparse, but the things that Doxygen adds (especially call graphs and inheritance graphs) add a lot more than what you would get just by browsing the source in an editor.

You might benefit from understanding key concepts in bitcoin before diving into the core source code. The following link teaches the technical basics of how Bitcoin works by walking you through writing a simple python script to create transactions from scratch:
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
Also on the site are other posts on how Bitcoin mining works and how to write a python script to mine Bitcoins (for science and understanding, PROFITABLE cpu/gpu mining days are long gone)
You might benefit from some fundamentals of what the Bitcoin blockchain actualy is. James D'Angelo is awesome at explaining concepts to everyone including beginners and more advanced users, without being boring or confusing. Watch the following video and check out his channel for more info.
https://www.youtube.com/watch?v=gUwXCt1qkBU

Mastering Bitcoin by Andreas Antonopoulos is definitely a good start. It's available for free.

Yeah, previous answers already mention it. Also, posting your amazon referral link here doesn't benefit you, as the Stackexchange engine automatically replaces the link with its own referral.

authors: сергій мележик


text:
What are 'pegged' side chains are and how they will be useful for Bitcoin?
What seems to be a very important paper was released this past week (http://www.blockstream.com/sidechains.pdf). It centers around the idea of 'pegged' side chains, and being able to move coins from one blockchain to another.
Can someone summarize how these pegged side chains would work?
How will they be useful for bitcoin?

Related: http://bitcoin.stackexchange.com/questions/32181/can-side-chains-or-pegged-chains-negatively-affect-the-security-of-bitcoin

Framed simply as a "how can it be useful to Bitcoin" question, has been covered; I'd like to hear how it complements what Bitcoin doesn't offer yet as this is the authors' theses.

Portions of this are copied from my answer to Scott's question.
This particular proposal only requires one change to Bitcoin: SPV proving.
SPV proving is required when you want to move Bitcoins from the sidechain to the mainchain. The idea is that rather than putting all of the rules to validate transactions on the other chain into the original Bitcoin client, Bitcoin clients would look at how much hashpower was used to secure the transaction. It's pretty clever, actually.
Destroying Bitcoins to fund other blockchains has always been possible.
One issue that I see is that I don't think there would be enough hashpower to secure the network from double spending; merged mining could probably fix that though.
Another weakness of the paper that I see is that it does not address what to do if someone does steal coins from the sidechain. (In other words, the Bitcoin network thinks there are 90 Bitcoins in the sidechain, but the sidechain thinks it has 100 BTC.) One possible approach would be to devalue all coins moved back to the mainchain by the percentage that was stolen. Another would be to take a flat percentage off the top of coins moved into the sidechain.


text:
Why are non-final transactions considered non-standard?
In IsStandardTx within main.cpp, there is a comment:
// Treat non-final transactions as non-standard to prevent a specific type
// of double-spend attack, as well as DoS attacks. (if the transaction
// can't be mined, the attacker isn't expending resources broadcasting it)
// Basically we don't want to propagate transactions that can't included in
// the next block.

What are the specific type of double-spend attacks and the DoS attacks alluded to here?

The denial-of-service (DOS) attack is easy to explain: each time a transaction is updated by increasing the sequence number in an input, the whole transaction needs to be propagated through the network again.  So if a transaction is 1 KB and there are 10,000 full nodes, you can waste a minimum of 10 MB of network bandwidth each time you update the transaction at only 1 KB bandwidth cost to you---and you can do it an essentially unlimited number of times with an essentially unlimited number of transactions, none of them costing you any money besides the transaction fee.
I'm not absolutely sure what the double spend attack referred to here is, but my guess is that it's the basic zero-conf double spend but with the network helping the fraudster: the fraudster pays you with a non-final unconfirmed transaction, being a trusting person you provide goods immediately, the fraudster broadcasts a double spend with a higher sequence number, the network mines the double spend instead of the original transaction, and you don't get paid.
It would be easy to block this type of double spend by refusing to accept into your wallet any unconfirmed transaction with a non-final sequence number, but that could lead to user confusion: "he said he paid me, and BlockChain.info says he paid me, but the transaction doesn't appear in my wallet!"

Thanks, David, you're very articulate. Couldn't the DOS attack be mitigated just by only allowing like 16 possible values for the nSequence? That way nSequence could still be useful. And the second attack makes sense, but it also seems like something that software just has to account for (don't accept a non-final transaction as payment for goods/services). Blockchain.info would only show it as unconfirmed, and that's probably what Wallet software should do too.

@StephenM347 Thanks.  Only allowing 16 values means only 16 updates are possible, limiting the utility of the field.  A main use was to be mostly-out-of-band micropayments where thousands of tiny payments would be advantageous.  I agree about the second attack being not very scary, but I can't think of a scarier scenario to account for the comment you pasted.  :-)


text:
Where is Bitcoin information (wallet.dat) stored on OS X?
Is there a wallet.dat for OSX? Where is it located?
Taken from https://github.com/bitcoin/bitcoin/issues/544

The Bitcoin wallet on Mac OS X is located in ~/Library/Application Support/Bitcoin/wallet.dat.

Mac OS X v10.7 (Lion) came out, and it has the ~/Library folder hidden, see the answer from chilled35 to access it with Finder.

In order to see hidden folders, such as ~/Library from Finder, simply hit shift + ⌘ (command) + G which will GO to a folder, then paste in this location:
~/Library/Application Support/Bitcoin

From there, you will see all the files associated with your wallet.

hmm I can't find this in Mountain Lion...

hmm, I discovered I can see it in terminal, but not in Finder.

Remember, this is the default location. If you installed Bitcoin a long time ago, you may have chosen another folder somewhere else... For example, mine was in ~/Documents/Bitcoin

In order to see hidden folders, such as ~/Library from Finder, simply hit shift + ⌘ (command) + G which will GO to a folder, then paste in this location:
~/Library/Application Support/Bitcoin

From there, you will see all the files associated with your wallet.
Having moved all my BTC to another location, I recovered more than 5 GB of storage space by deleting my local wallet.


text:
Do transactions and blocks get relayed even if a node believes them to be invalid?
Each node has a very clear view of what is valid and what is not. With conflicting blocks (Blockchain fork) or transactions (double-spending attack) it will always choose the first it sees, until it gets prove otherwise (longer blockchain or other transaction is included in a block).
I'm wondering whether the Satoshi Client relays any of the transactions or blocks he thinks are not valid. So will I ever see a transaction if all my neighbors have seen a conflicting transaction first? Will I see forked blocks if all my neighbors agree on which block came first?

A block is valid only if it obeys all the protocol rules.  If it is invalid, it will not be relayed:

http://en.bitcoin.it/wiki/Invalid_block

Now the client does maintain side chains.  So if there is the main branch and a side branch, even though the node included a transaction in the main branch doesn't mean it will reject a block for the side branch just because it too contains the same transaction.  So for each branch it is determined if that block was valid or not.
But there is a rule that valid blocks are only relayed if they are added to the (new) main branch / best known chain (thanks to Pieter for the correction).
As far as a new transaction being relayed - if it is invalid for the main branch (e.g., double spend) then it will not be relayed by the node.
So a transaction is either already in a block in the main branch already (and thus would be rejected if it is a double spend) or it isn't in the main branch and will as a result always be relayed.
This will be relayed even if that transaction is already included in a block in the side chain.

Almost correct. Only valid blocks and transactions are relayed, but for blocks there is another rule: they're only relayed if they are part of the (new) best known chain. Relaying blocks in sidechains is usually a waste of work anyway.

@PieterWuille, Doesn't this depend on the client? What's stopping a rogue client from relaying invalid blocks?

Nothing. Which is why everyone else who cares verifies them :)


text:
Does Dojima (trading platform) have access to my funds?
I would like to use Dojima to trade bitcoins on Bitstamp.net. However, I would like to know about security.
Does Dojima have the ability to send bitcoins to addresses, or is it only able to submit trade orders?

Yes it could do that. Luckily, it is open source, so people can check the code to ensure Dojima will not secretly send funds away.
If Dojima connects to Bitstamp for you, it will use the username and password of your account on Bitstamp. This will allow all functionality offered by the Bitstamp API, which includes sending bitcoins to an address.
You will receive an email to verify the transaction, before it is initiated by Bitstamp. This is a security setting you can adjust in your account:
https://www.bitstamp.net/account/security/email-confirmations/
Let's hope Bitstamp will issue API keys shortly, which you can set to "trade only" for example. That would prevent you from having to enter your password in third party applications.
Update 2013-09-23: Bitstamp added API keys https://bitcointalk.org/index.php?topic=38711.msg3218202#msg3218202


text:
Will it be possible to export a key and only allow it to be imported once?
When the import/export key be implemented I would like to know if it will be possible to export a key with an option like: The exported file can only be imported one time, or that the exported key was exported with an option that removed the key from the wallet that exported it. I ask this because I would like to receive for example a exported key file from someone but with the certainty that the key is not on this someone wallet anymore (or any other wallet).
Will this be possible?

No, there is no way to keep track of what people do with their private keys. You could easily write down the key before exporting it and you can use it without ever importing it to a wallet. It's possible to construct a transaction from the private key manually or using some 3rd party software and then broadcast that transaction to the network.
It sounds like you want to be able to send money without using the blockchain by simply passing private keys around. You then run into the double-spending problem. This is exactly the problem that the blockchain is solving. So, no, if you want to securely send bitcoins you will have to use the blockchain.

The only way around this is to obtain a privkey from a trusted source which is protected by some kind of tamper-evident mechanism. This is the way BitBills and Casascius' physical bitcoins work and even then you still have to trust the issuer not to keep a copy of the keys themselves.

And though the details elude me at the moment (and Google fails me) I want to say I'd heard a workable scheme someone cooked up for when multi-signature transactions become available.

Hi David, if you find this workable scheme, please post here. Thanks

No it would not be possible. The exporting party can always keep a copy of the key if it so desires, simply by making a wallet backup prior to export. You should always assume that any keys/wallets that you receive from others have copies retained by the sender.

No and trying to do so breaks the security of bitcoin.
If you want to send someone coins then create a transaction.  This will be verified by the network and the wealth can be safely and irreversibly transferred.
A bitcoin address merely consists of a public key and private key.  The address doesn't store any other secret locally (like a code which determines how much it is worth).  The client (and any other client) can determine how much a particular address is worth by using the network.
Given that an address merely consists of two keys (strings of numbers) there is no possible mechanism to ensure that when you are given a copy that no other copy exists.
One thing you can do:
Immediately verify the coins still exist and then transfer it to another address you own (one which has a secret private key).  Once confirmed that transaction is irreversable and your funds are no longer at risk.  The "potentially compromised" address can then be deleted.

This is impossible in principle. It would take a physical hardware security device to prevent someone from replicating the key or generating a signed transaction with the key while they have it that they can publish later.
Instead, you generate the key and give them the address. Have them send the Bitcoins to that address. You will know that only you have the key because you generated it.

By design, Bitcoin has only one owner, a key has many.
Only the coins guarantee unique ownership, otherwise it would be a nightmare, backup-wise.


text:
Will be possible to have the same key on more than one wallet?
On pull request https://github.com/bitcoin/bitcoin/pull/220 say will be possible to import/export keys.
I would like to know if will be possible to have the same key on different wallets and only be able to spend the bitcoins from this key with permission of the other users that has this same key on the wallet. Example:

I have a key on my client with 10 BTC.
I export this key and send to a friend
The key will be on my wallet and on my friend wallet
When I or my friend try to spend the bitcoins from this specific key, will be requested a password asking if we accept the transaction.

Will this be possible on next Bitcoin versions?

I think that the title of this question should be changed. It seems to be more about requiring permission from two different people to send funds and less about having the same key in two wallets.

The pull request that you refer to is just for simple import/export of private keys and wallets and does not include the feature that you want.
There have been some discussions on multi-signature transactions which sounds similar to what you are looking for. That would allow for cases where two different private keys are required to make a transaction. See this forum thread and the draft proposal here.

Tell me: With pull 220, what will happen if I import the same key to two different wallets?

As both wallets will have the key with the ability to spend the coins, both can spend it. The first to spend it most likely decides where the coins go. The other will see the debit transaction appear. If you try to do two spendings almost simultaneous, you're effectively doing an attempted double spend. The netwerk will cope, but the wallet will not.

Sipa: Will be possible to have a feature where I know that a exported key it's not in any wallet? If someone export a key and send me, I would like to be the only one able to spend the btc from this key.

If you want to be the only one controlling a key, there is one simple solution: use a key you generated yourself. If you want to accept funds available to a key as incoming payment, do a transaction yourself to send the funds to a new key. There are plans for a "sweepprivkey" command that would do this; it hasn't been implemented, though.


text:
Blockchain.info keeps sending wallet backups
Blockchain.info is sending my wallet backups over and over again;
is this someone trying to hack my wallet or something else?
I haven't done anything on my account, no settings changed et cetera.

This is standard if you have backup wallet chosen in your settings. Alternatively, email backups will send a wallet.aes.json file to your specified email address. A few things to keep in mind:

The aes part means your wallet is encrypted using your Blockchain login (and secondary password). If your password is changed then your newer wallet files can only be decrypted using the new passwords
The json part means the decrypted aes is a readable json format which can be read by humans and imported by various programs
Changing your password will change your decryption mnemonic.

The backup wallet.aes.json files are good for recovering old wallets but if your BTC has been moved from those addresses it does not recover your money.


text:
Transaction rejected by our node. Blockchain receive API
I use the Blockchain.info receive API with great succes.
Yesterday I created a new address: 1MMVp6fzZ6QrVYXg9iRSJb5PsM8crq5iMZ
It received 1.5 BTC and was transferred to my BTC address (unfonfirmed). With transaction hash: 79ff50d749d1d8099e68ac04dba4e64645322e49e671326d74d871bfd0f868eb
Today I logged in on my wallet, the unconfirmed transaction was gone.
Now if I search that hash on blockchain.info, I get following message: Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned from our database.
Will the Blockchain API retry to send the BTC to my address or are they forever lost on the generated address? Would it make sense to make a small payment to that address so the Blockchain API would resend the whole amount?
Why does this happen?

How much transaction fees did you add to that transaction?

Oh, blockchain.info generated that address, and they were supposed to forward that amount to another btc address and it didn't happen?  And this is a free service and no customer support?  Well, sucks to be you ... :-(

It seems to be a mixup at blockchain.info. They show the deposit as confirmed in some places and not in others.


text:
Development environment requirements for Bitcoin Core
Can someone help me out in understanding the System Requirements and dependencies required for setting up a development environment for Bitcoin Core?
What else is required apart from the Bitcoin Core source?

What did you try? What errors did you encounter?

Please explain what you actually need.  Is there something missing from the development documentation?  Best to try it first, then post specific questions or problems here if you really cannot find the answer via google / or search on this site.

All the info you should need is here:

https://github.com/bitcoin/bitcoin/tree/master/doc


text:
Why don't addresses in an (unencrypted) wallet.dat file seem to match addresses that would be generated by the private keys in the wallet?
I've been messing around with an empty wallet file using the 'pywallet' utility, and have come across something I can't understand.
A dump of the unencrypted wallet readily reveals a list containing entries such as:
        "addr": "1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT",
        "hexsec": "d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0",
        "reserve": 1,
        "sec": "5KRTGtTczAwef7vdDfm9knDyKMoaa8XHJURnMZnQFd5qkWVJtsB"

The second/fourth entries are obviously the private key.  However, if I input this key at (for instance) bitaddress.org, it generates
        1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 (address)
        1HoVqjG35pW3AQ7wtYtA72tSpyLyP4vDLp (compressed address)

neither of which match ANY of the other addresses listed in the dump.  I can't find an explanation for this anywhere, and I'm wondering what the ramifications of losing, say, the first address in the key entry ('1NpYUP...')  or the addresses in the pool are if they don't actually correspond to the private keys in the file.
Just a heads up - do not post your private key in public unless you'll no longer be using that Bitcoin address
Thanks in advance!

Have you tried sending 0.01 BTC to 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT and to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8?

I have not, simply because I won't feel comfortable using Bitcoin until I get a really good grasp of how everything -- especially the client, which I would use most frequently -- works.  Because of this, I have only the 5 mBTC I got from the Bitcoin Faucet; not enough to avoid incurring a fee I can't yet afford!

You can get a tiny amount of daily free bitcoins if you can put up with ads. I don't do this much, but it's perfect for seeding addresses. DailyBitcoin and CoinAd are two places that do this.
Note: I have absolutely no interest in these site's success except for the few times I use them.

Importing the private key (d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0) into Blockchain.info/wallet also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8.

I used my GoBit testing suite and it also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 http://gobittest.appspot.com/Address

Doing my own testing with pywallet, I find that 1. the output format is slightly different (no hexsec) and 2. I don't have this problem on a newly-generated wallet.
This makes me think you have a bad pywallet version, or a bad wallet file. Could you please post the pywallet version you're using? Also, could you try sending some of the bitcoins you got at this address to see if you really do have the right private key in the wallet?

I believe I'm using the latest version, pywallet.py 1.1.  I've continued to experiment with this, most recently using the utility to add that same private key and the associated address (1EEYqe...) to the key pool.  This did not overwrite the entry containing the same private key but erroneous address (1NpYUP...).  Adding the private key manually a second time does result in an overwrite of the 1EEYqe... entry, but again, the original is untouched.  Very interesting!

Have you had any luck sending bitcoins from your 1NpYUPp... address?

Yes, I was able to send some from the 1NpYUPp... address to the default wallet address without problem.  So the correct private key has to be in the wallet somewhere, right?

I'd assume so. I'd try importing the wallet into another service and see what happens. Blockchain.info has at least two different ways you can import it, probably more; I'd check what those do.

Importing the pywallet dump into MyWallet doesn't seem to do anything.  There will even be 'verified' and 'successful server sync' type notifications, but the BTC balance and transactions will not appear unless I import each private key individually.  Oh, and I haven't mentioned this yet because yet as it seems irrelevant, but I do not have a working 'ecdsa' package installed.  Could it also have a subtle influence on the mismatched key issue I'm experiencing?

Just following up, I did get the 'ecdsa' package installed for Python 2.7.  As expected, it had no impact of any relevance.

What private key does the dumpprivkey command report (RPC call or console in Bitcoin-Qt)? Does it correspond to what pywallet is saying?

My experiences messing around with all this tells me that the fault probably falls with my particular version of pywallet.  Specifically, it is simply reporting the private keys inappropriately.  The primary reason I think this is that the addresses in the pywallet dump corresponding to addresses that can both send and receive coins using the Bitcoin-qt client.  Additionally, the pywallet utility can add its legitimate private keys to the wallet, and there's no problems -- the address and associated private key in the 'keys' entry match up.  Hence, it's just a problem of reporting the correct results.
What I still don't get is why how the keys pywallet spits out are still legitimate.  It's almost as if instead of using the private keys actually associated with each address through the client, it's generating its own.  But I'm not terribly well versed in cryptography yet, and that's just the thoughts of a mind desperate for an explanation!
I'm still unsure of how to fully resolve this matter.  I'd hate to ``downgrade'' my version of pywallet, so to speak, but it may be worthwhile to see if an older version behaves as expected.

Perhaps pywallet is misreporting the bitcoin address?
Does your wallet actually show a 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT bitcoin address?
Here's a method to manually determine the public address for the private key.

http://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Thanks for the response.  The default address the wallet displays is 19x2Ma982vmtk5uJX7cb2WkEMcvYgCEAmz.  Excluding this, the first address in the key pool according the pywallet data dump ("n": 2) is 1Hc7xyoBUBpvjtcr6LTmpQSssvPWGbtt8u; after firing up the Bitcoin-qt client and "making" a new address, these are indeed the addresses it displays.  I'm inclined to say that the addresses in the key pool are the real deal, but it's still strange how the private keys listed in the dump don't match them.

And for the record, when I get time tomorrow, I may swallow my pride and get a pittance of BTC tomorrow from those advertising sites, as per Daniel's recommendation.  Then I can try sending them to the various addresses and see if I can recover them in any way.

This escaped my notice initially, but my the 1NpYUP... address does actually appear in the key pool, at n=5!  Indeed, some coins I sent there were received successfully and shortly thereafter began acquiring confirmations, as is typical!  I've since realized that all of the addresses listed under the 'key' category also appear in the key pool, but with an order that seems random.  BUT, this still doesn't explain why the pool addresses the private key associates with under 'addr' don't match up with the addresses generated by the private keys!

I should also add that BTC sent to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 never were received, despite that the private key from which it originated is in the wallet, according to the dump.  I don't know what exactly this incriminates.  Also, apologies for the quadruple comment!

Well, somebody received those coins and spent them, probably because you posted the private key here. If you decide to use bitcoin for values of more than a few mBTC, you should probably generate an entirely new wallet separate from those here, or at least ensure you NEVER use these addresses again.
http://blockchain.info/address/1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8


text:
With Ripple, what is "Close Resolution?"
In the spec for the ledger format, there's something called "Close Resolution" in the header. It is described as "the resolution (in seconds) of the close time." What does it mean, and what is its significance?

Ledgers do include a close time because it is expected that contracts will be able to support things that can "expire" such as escrow. However, validators might see a ledger close at very slightly different times owing to their slightly different network views and errors in their clocks.
To resolve this, Ripple uses a close time resolution. Validators announce the close time they actually saw to help their clocks stay in synch, but they only try to reach a consensus on the rounded close time.
If validators ever fail to reach a consensus on the close time (and this has happened a few times), they agree to disagree, indicate this in the ledger, mark a close time one second greater than the previous ledger, and (if it keeps happening) raise the close time resolution to make it more likely they'll agree.
If validators consistently do agree on the close time and the close time resolution hasn't reached the minimum (10 seconds, I believe) it will decrease until it reaches that minimum.


text:
With Ripple, is it possible to have XRP IOUs?
Just as there are USD IOUs, EUR IOUs, BTC IOUs, and so on, is it possible to have XRP IOUs in the system?
If yes, could XRP IOUs be used as transaction fees?

We debated how to handle XRP IOUs during the design. Ultimately, we decided not to have any official support of them because of the potential for user confusion. However, we did reserve the currency name "XRR" for IOUs denominated in XRPs. There is no built in mechanism to pay them off with XRPs, but it's not difficult to place a 1-to-1 exchange offer. Such functionality might be added in the future.
We also debated allowing IOUs to pay transaction fees directly, rather than having to first exchange them for XRP. We couldn't see any advantage and there are some significant disadvantages in addition to the added complexity. The big one is the exchange rate might change such that the transaction can't claim a fee and we wouldn't discover that until the transaction was processed. There was a fear someone could bombard the network with such transactions and cause high load at no cost. Instead, we decided to try to keep transaction fees so low that there would be no reason to care.


text:
With Ripple, how is base fee (transaction fee) calculated?
The Ripple wiki says (emphasis added):

If the reference transaction should cost 10 millionths of a ripple, the "base fee" should be set to 10. This is the current value. This makes it very simple to adjust fees to keep them sensible -- just figure out how many millionths of a Ripple the reference transaction should cost and set that as the base fee.

Yes, and how does the system figure out what a reference transaction would cost?
It would be great to know how the transaction fee is determined and how it is adjusted in response to deflation (rising value of XRP or falling supply of the units).

Manish, you're flooding a lot of Ripple questions onto here at a higher rate than people can vote on them or answer.  Can I ask why?

@eMansipater Yes, sir, you may ask, and I can tell you that I was reading the specs and I posted the questions as they popped into my head. Is that bad form? I could just write down my questions in a text editor and post them at intervals of an hour or two, if that's better. I certainly didn't mean to "flood" anything.

no real problem.  Sometimes flooding a lot of questions is an indicator that someone doesn't quite get how to use Stack Exchange so I was curious where the questions were coming from.  Would you say that the sorts of things you were asking about are missing holes in the existing Ripple documentation, or more just that you were using this as a way to kind of get Ripple into your head?  Generally Stack Exchange works well for individual answers where someone will take the time to give an an-depth answer.  With the rapid fire style you might have better luck on the Ripple forums.

(You'll note that although David Schwartz was able to keep up with basic answers he didn't really have time to answer all the questions in depth.)  Stack Exchange shines best when someone can take a few specific questions and answer them so effectively that anyone in the future of the internet would prefer that answer to any other treatment of the question.  When questions are getting fired off too fast, it's hard for the experts to provide that level of detail and quality.  That's all.

@eMansipater Frankly, I don't know what you're talking about. If you can point me to one question I posted about Ripple in those few minutes that didn't meet the quality standards of this site, then I'll admit you have a point. If the documentation already contained the answer, then I wouldn't be asking the question. "No real problem." OK, case closed!

"point me to one question"--it's not really about that, more about continually improving the quality of the site.  One weird thing for people to wrap their heads around with Stack Exchange sites is that even an obscure question will often be used by 50 people who later visit, and more than 20,000 people for a really good one.  So the real trick to creating a good Stack Exchange site is working to make questions and answers 20,000 times better than they "need" to be.  That's what people like me are always on about--the 20,000 other people who could benefit from an improvement.

@eMansipater Thanks, I really appreciate the work you put into the site. I have learnt a lot from it for sure.

The base fee is contained in the ledger and can only be changed by a pseudo-transaction that gets into the consensus set. It's managed by consensus the same way the reserve levels are.

"It's managed by consensus the same way the reserve levels are" Details on that process are here: https://ripple.com/wiki/Change_Process