Coins are safe because your transactions will exist in the 0.7 blockchain too. Only issue is double spending and that's why you should not buy any coins from anyone right now.

PLEASE don't trade with anyone offering good deals right now There is a very good chance they are trying to take advantage of the chain fork.

IF YOU ARE NOT MINING just go do something else for a while!

Anything with more than 11 confirmations (at block 225446) is safe, anything with less may or may not be but all transactions will be retried so bar intended harm there should be no issue for users.

Just don't trust coins with less than 11 confirmations at this point, better yet, don't use your client for the next few hours at all and everything will come back to normality.

Oh, but it does, at least if you do "account_tx account ledger" for a specific ledger id (as opposed to a range).

Still haven't had a chance to try this over a better machine but I'll report on that once I get it done.

Yes, I did. Had I not done it there would be an error 'No such ledger'. It also dawned on me I'm using a very low end 32bit machine for this, not all that much ram also. I will try to run this on a separate system that has proper server specs.

I removed the whole db directory, so I'm sure that's not it. I have now built from a clean checkout, started without any database, ledger_history is 65536 and... it still happens

If I issue the same account_tx to s1.ripple.com it returns the correct data, but against my local ripple it gives me nothing (for the source address, it is correct for the destination address). I have a small debug log that I will provide you, but it gives you little to nothing from what I could read.

Can you tell me the exact revision that is running on s1.ripple.com? Are there other public servers I can try the account_tx command against?

Same difference,

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675 339675

Connecting to: 127.0.0.1:5005
{
   "result" : {
      "account" : "rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX",
      "status" : "success"
   }
}

Oh, well, gona build from a fresh checkout now

I have nuked the db and changed ledger_history to 65536, now waiting for rippled to catch up with the ledger in question.

What was happening was: I had the ledger (339675), a 'rippled ledger 339675' would show it (in full default with 'full'), and then:

./rippled account_tx rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt 339675 339675
would show the transaction

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675 339675
would not (but not with a 'ledger not found' error, should wouldn't show any tx detail).

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675
./rippled account_tx rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt 339675
Both the above commands would also not show errors nor anything about the tx.

Running any of these commands against s1.ripple.com does work as expected, so it is something local to me.

"complete_ledgers" : "339007-341774"

source @f3b837eea654deec3572a89a000f2b6e13156f6a, same issue. I'll nuke and start afresh, probably something went sideways with my deploy.

Sure, I'm kind of, sort of aware of that (I didn't know to look for complete_ledgers) but since I get one half of it, the received payment tx, I should have the ledger, right?

This does present a separate issue, though; how much is enough? If I start the server with history to 256, does that mean it prunes history to last 256 while running, or just that on startup it requests only the past 256 ledgers (if they aren't already local).
I guess my question is how to properly handle long periods between polling the server for new tx.

@JoelKatz it appears this only happens agains my local rippled, so something must have gone wrong with it. I'm recompiling to the latest, but if it keeps happening is there something you'd want me do before I nuke everything out and start from scratch?

Nope, I'm asking for 2 tx only. I'll send you the exact query tomorrow (work computer already off for today).

For my current use case I need a polling approach to following up transactions (as opposed to subscribing to events). This is all fine for payments received but I can't see any reference to payments sent from the source account. I can in fact see the transaction received on the destination.

Is this by design? Shouldn't payments sent also appear in account_tx?

Changes to the payout system are effective now. Let us now of any concerns or issues you might have and...

Good luck!

Last bump regarding the upcoming changes posted above in https://bitcointalk.org/index.php?topic=120239.msg1598128#msg1598128

Next post on the subject will be to say the changes have been applied

Chances to win 1 DYM at TAABL.net!

Currently 1 DYM goes for ~$2 or roughly 0.045 BTC, so I have started a BitPick for 1 DYM (there will be two in total, one after the other) with bets priced at 0.005 BTC.

NOTE: This is a Pick 2, meaning it will win when the first 2 hex chars of a block hash match your bet, so it will likely be awarded quickly and with a very small bet count! You need to act fast if you want it

Common BitPick rules apply, the winner must be able to sign a message with the sending bitcoin address private key.

I don't know the specifics of the contracts between nodes, if there are any, but while ripple is fundamentally different from bitcoin it does have one thing in common, the network is distributed which means that as long as there are 2 nodes, the network is alive between them (though disconnected from the rest, if there is a rest, and reconnection may invalidate things that diverged, just like in bitcoin).

So, when you said ripple dying I assumed no nodes communicating. Since I can run a node myself I have a copy of the ledger locally. Keep in mind ripple is still closed beta to some extent so there are not enough nodes in the wild to support the network on such fails, which is a good thing at the moment as the rules and code are still being tweaked and the ripple team has some control over which versions are available and thus prevents network partitioning.

As for you question to TTBit, let me try to explain. The person who took delivery gave back the IOUs to TTBit, which means TTBit doesn't owe that person the 10 dimes anymore... this is the real kicker, we usually see money as something of substance (even though that is more often than not untrue) but in this case there is no misunderstanding, having a DYM is not having a dime, in fact TTBit has no DYMs at all, there's no such thing for him as the issuer. What there is is a balance of dimes TTBit states he has and owes you. When he sends the coins and receives the DYMs he is in reality destroying the DYMs, because he owes them no more.

This means that if a bunch of people wanted delivery, that bunch of people would hold IOUs they would be redeeming and TTBit's "DYM contract" states he holds the physical dimes for every DYM issued, thus he would most simply send out the dimes and the IOUs would be extinguished.

Now, if demand would rise and he wanted to put more DYM into the market, keeping with the rules he put forward initially, he would have to acquire the dimes through whatever means he chose and hold them physically before issuing more IOUs, but that's just because he chose to do business like that.

You can choose to say you'll sell DYMs without holding dimes, but you can't sell TTBit DYMs without him holding the dimes, and for you to sell your own DYMs others need to trust you for them.

Also, beware of extending trust to individuals (as opposed to issuers). TTBit is DYM's issuer, so that is fine, but trusting him for BTC at this moment may give you some grief, not because he is not to be trusted but because Ripple isn't yet handling that as well as it should (but that is being fixed).

As for the "two week old" part, consider this; If you hold silver and you store it in a bank's safe (not saying you do, just go along with it) you hold the silver, it is yours, not pegged to the dollar and all but... you have to trust the bank to not steal your silver. That's what is happening here, you are trusting TTBit to hold the silver for you. Ripple is just a ledger, and a public one for that matter, meaning that if tomorrow ripple just dies, never to be seen again, I'll  still have access to that ledger and, even if I didn't, you trust TTBit to give you the silver as per the DYM you held so as long as you can convince him you actually held that much.

Ripple facilitates all this and is an amazing tool for that, but we are used to dealing with 3rd party insurance, banks are audited, we have protection so we don't need to do due diligence to assert we are dealing with small or no risk. With bitcoins and ripple there's a dramatic change there, we are solely responsible for whom we trust and (with ripple) for how much we trust them. Ripple facilitates, keeps books, processes transfers, but it is your responsibility to know there is no recourse, trust only those that you actually trust and for how much you trust them.

It doesn't need to be an option, you can manually type it in.

I am "completely neutral" about DICEonCRACK and we are trying to prevent getting into the same spam issue as SD by grouping payouts as best as we can: https://bitcointalk.org/index.php?topic=120239.msg1598128#msg1598128 and by providing a wallet proxy (for now only on IRC) that does not signal losses with dust transactions https://bitcointalk.org/index.php?topic=147722.0

I honestly believe that a proper solution needs to be found for the transaction spam issue for bitcoin as a whole, not targeting any specific service as this is severely needed to ensure bitcoin will survive globalization. Also, each miner has the freedom to choose which transactions to include in the found blocks, period. I wouldn't join a pool that filters anything because I believe the prioritization currently in existence is good enough. I'm invested in bitcoins for many reasons, not the least of which being the lack of central authority. We can boycott but we can't ban, simple as that, only a majority vote can steer the network one way or another, not an institution or a core group of developers.

This post started as a simple shameless plug "look at me, I'm trying neat solutions here" but ended up with my personal view of the problem... I need to learn to stay on topic!