If you've had bitcoins sitting in a wallet since before this happened, they are safe. Just don't do anything with them until the problem is resolved.

Perhaps you didn't get the memo, but Bitcoin is broken right now. Bitcoins cannot be safely transferred on the blockchain.

They cannot use Bitcoin anymore. If you're going to run a Bitcoin client, you have to keep it up to date and follow announcements. Otherwise, all kinds of terrible things can happen.

It is vital that the decision to make this kind of change in the Bitcoin protocol be consciously made. What if the next change is to keep the block reward at 25 bitcoins forever? How easy do you want that to be?

Yeah, through a coordinated process. Most likely it will go like this:

1) We'll pick a block number on which to switch.

2) A new .8 version will be released the switches as of that block number.

3) It will be announced that everyone must update before that block number.

4) The switch will take place automatically.

Yes, they're safe. (You should make sure to keep the old wallet just in case, but since your transactions were done yesterday and presumably many people will re-run all lost transactions, it shouldn't matter.)

1) If you run a mining pool or are mining solo, and have upgraded to 0.8, downgrade to 0.7

2) If you are a normal user, do not perform any important Bitcoin transactions until you get the all clear.

3) If you are a pool miner and you know your pool has not downgraded, stop mining.

4) If you performed any transactions recently, be warned that you cannot rely on them.

You're correct. It's kind of a quirk in the code. If you specify a ledger range, special code for ranges of ledgers handles it. If you specify one specific ledger, generic code that fails if the ledger isn't available handles it.

I don't think account_tx will ever give you "no such ledger". You can query for transactions from ledger zero to ledger one million and it will give you the latest 200. (Arguably, it probably should tell you which ledgers it has in the reply, but you can always check, it's published to the "server" stream.)

We don't test extensively on 32-bit machines. 1GB should be sufficient. If you have less than 1.5GB, leave your "node_size" at "small" (the default). This will cause the system to use less RAM in exchange (mostly) for more disk I/O.

You waited until your server reported that it had the ledger? That's the only thing I can think of. I'll look over the code just in case there's something I might be missing.

It's the head of the git repository as of this morning:

commit 92318a47bd59659e2dbfde174b14893ee2fe4afa
Date:   Sun Mar 10 19:15:28 2013 -0700

Say I have USD at Bitstamp but I need to pay someone who only accepts USD from WeExchange. A liquidity provider is someone who will accept USD from Bitstamp in exchange for USD from WeExchange. Using that liquidity provider, I can make my payment. If you tell Ripple that you equally value USD/Bitstamp and USD/WeExchange, whenever you hold one of them and are below your limit on the other, you act as a liquidity provider automatically and may find your balance shifting between issuers from time to time.

Unless it also brought in new players or increased interest from existing players. It's all about supply and demand.

More importantly, I think we all know that Bitcoin's key to long-term success is increased adoption as a means of exchange. Deflation harms that because it means that prices need more frequent adjustment. A small amount of inflation (assuming it is gradual and small, rather than sudden and huge) would actually be a good thing. It would also help to drive out speculation, which would decrease the risk of a bubble collapse. Collapses are disastrous to adoption because they make Bitcoin risky as a means of exchange. So anything that drives off speculation is good for Bitcoin's long-term success.

It's all about supply and demand. A new world that uses a virtual currency also adds to the demand for goods that can be purchased with virtual currencies.

But I might be a bit of a contrarian because I think looking at the price of a virtual currency (in units like dollars per bitcoin) is useful only so long as it accurately measures adoption of the currency. If other factors push the price of the virtual currency up or down, we shouldn't care. Bitcoin's success will depend on how widely adopted it is. To the extent price measures that, then it's a measure of success. But to the extent it doesn't, it isn't.

In fact, to the extent a higher price means more speculation, that can be a bad thing. Speculative bubbles can burst which can cause sudden drops in price. Those drops increase the risk of using the currency as a means of exchange which drives adoption down.

We should care about adoption of Bitcoins as a means of exchange. That's what will determine Bitcoin's long-term success, or lack of it.

This could potentially happen if you wiped your transaction database but kept your ledger database. The ledger database would tell the server that it had processed the ledger and didn't need to re-process it. The 'account_tx' command uses part of the transaction database to find all transactions that affected the selected account.

Data scrubbing is on our road map. This will also allow us to remove old data that's no longer referenced, if desired. (This is not as simple as it sounds because we know when we first fetched data, but whether that data is still in use or not in use, it sits there just the same. So we'd need to do background scrubbing to determine when we stopped needing it.)

Are you saying there's a transaction you know was placed in a ledger inside the range of completed ledgers you have and account_tx isn't showing it? Or are you saying your server isn't acquiring a ledger it's supposed to acquire?

You can use account_tx against our server to get the 'inLedger' field to see what ledger a transaction was included in. Then check your server to see if it has that ledger. If it doesn't, make sure it's configured such that it should. If it should have it but doesn't check server_info every few minutes to see if it's still acquiring ledgers.

By default, the server only acquires 256 back ledgers. You can set the history higher if you want (search the config file for "ledger_history"). If you don't have the ledger a transaction is in, you can't provide the transaction to clients who ask. If you look in the 'server_info' output, you'll see a field called 'complete_ledgers'. This is the range of ledgers your server has fully indexed and locally available.

Payments sent should appear in account_tx. Perhaps you're trying to query for too many transactions at once? The limit is currently 200 transactions in most cases. The transactions appear with the most recent transactions first, that might be throwing you.

The client source is available.
https://github.com/rippleFoundation/ripple-client

As discussed elsewhere, the server source is not available yet. (The primary reason is that once other people are participating in the network, changes are as difficult as Bitcoin hard forks. That would slow the rollout of new features. So we'll delay releasing the server source at least until the feature set is reasonably complete. Once the network is distributed, we want people to be able to rely on settled expectations even if that means not adding new features.)

Technical details are available on our wiki and, if necessary, simply by asking us. I can't promise that I'll have time to answer every question, but we aren't hiding anything and so far I've been able to answer every technical question that's been asked. You can also find ledger and transaction structures available for download.

The deception is that the repayment (in one example) or coverage (in the other) was unconditional when it was not.

In any event, on this forum, we use the 'scammer' tag for people who could easily, but choose not to, make good on their promises, whether there was deception initially or not. We don't have 800 different tags for fine legal distinctions in how one person can rip off another.

So if Pirate had been investing people's Bitcoins in another Ponzi scheme that he himself believed was legitimate, he wouldn't have been scamming?


If you fail to make good on an obligation, that can be a scam even if you never previously considered how you would handle the particular situation you wound up in. For example, say I irrationally believe that I can't possibly lose at blackjack. If I borrow $400 from you to play blackjack, then lose and choose not to pay you back, you can reasonably describe me as scamming you. This is true even if I was positive I'd win and fully intended to pay you back from my winnings. So long as I represented that repayment was unconditional and I never intended to pay you back if I lost, it's a scam.

That is what is alleged to have happened here. The claim is that Coinabul conveyed the representation that opting to buy insurance ensured that the buyer was covered against the package being lost or stolen in shipment when Coinabul never intended to make good on that representation if the insurance carrier failed to make good. This can be a scam even if Coinabul never considered the possibility that their insurance carrier might fail to make good.

You can never prove prior intent. Any accused scammer can always claim he decided to keep someone else's money at the last moment.

If your negligence causes someone harm and you don't compensate them, that's evil. Negligence is not evil, so long as you compensate people when it causes harm.

The miners face a "take it or leave it" proposition. They can either include a transaction or not. If they don't include a transaction because they'd prefer a higher fee, they just don't get any fee at all. A miner who insisted on higher fees would likely just wind up getting less because he'd be including fewer transactions in his blocks.

It's basically zero, or nearly zero. Enough miners will include any valid transaction that you can pay basically no fee and still get a transaction in.

Each miner decides for themselves which valid transactions they will or won't include in blocks that they mine.