So in short, you people do not read, you just make up out of your own childhood's fairy-tales the same fairy-tales you were told to put you asleep way back when; the very fairy-tales the reading linked to debunks.

Geniuses.

-MarkM-

Hmm, that kind of undercuts the regressive theories of the Misers Institute, eh? Interesting...

-MarkM-

Sounds like you're after Josh's job...

-MarkM-

That sounds like the same kind of thinking that has people expecting GRouPcoins to be worth one thousand DeVCoins.

But consider relative difficulty. GRouPcoins are much much lower difficulty than DeVCoins so although only 1/1000th as many are minted, it is much much easier to mint them.

Plots of their relative prices are at http://galaxies.mygamesonline.org/digitalisassets.html

-MarkM-

Open Transactions doesn't need history, the last signed receipt for an account acts as its balance.

Basically you should be able to get away with account number, receipt number, transaction, and balance.

The receipt number might as well be per account, that is, it shows the sequence of this receipt, in the (not actually needed anymore) history of receipts relating to this account.

It would be signed by the account's owner, so you have proof they acknowledged that was their balance, and the part I listed as transaction could be an entire signed by all parties contract or transaction, like "five bucks from so and so, see their receipt number such and such, goes into this account that this is itself a receipt for" type of thing. Maybe including the balance that resulted in each account involved, as well as the amounts that went to or from various accounts.

If anyone can produce a higher receipt number for this account, signed by this account's owner (or by this account, if account and owner are the same thing in your system rather than accounts being owned by nyms or identities or keypairs other than the account itself considered as a keypair), then that is proof this receipt is out of date.

Any change in a balance presumably means some amount went somewhere else, so that somewhere else's corresponding receipt can be looked up to see if it is indeed signed by that somewhere else.

Zero balance accounting practices can be used so that each transaction must balance out to zero, so that two people cannot collude to both sign receipts that basically say each of them gained; anything one gains another must lose.

Putting it like that it actually isn't at all obvious why Open Transactions uses a centralised server; as it kind of seems like if all these receipts were in a distributed hash table anyone and everyone could check the balances of all the accounts and that the grand total is always zero.

-MarkM-

Does *coin-qt even let you turn off the stupid notification stuff, tell it not to clutter your desk with icons/widgets, stuff like that? I recall when I did run it it was a constant source of pointless distraction whether from work I was trying to do on another desktop of the GUI on the machine or even just trying to catch some television while puttering on the computer at the same time.

Or I could be partway through writing a forum post and some stupid bid for attention would happen, as if I wanted to know every time any account of any of the umpteen coin types mined a block or had some other transaction happen.

GUIs are unfortunately hard to avoid nowadays for things like browsing but can be very annoying.

I have some stupid icon at top of screen right now that seems to be a link to a web page and right-clicking it has no delete option, lefclicking it tries to visit the page, and middleclick does nothing. There were two at one point and I got rid of one somehow by dragging it somewhere and dropping it but no idea why that worked - I didn't drop it in a trashcan picture - and dragging this remaining one didn't make it go away last time I tried. Last thing I want is to fill that bar with icons for bitcoin, namecoin, devcoin, groupcoin, ixcoin, i0coin and coiledcoin just because DiabloMiner is merged-mining on p2pool somewhere in the background (neither, thankfully, blipping icons at me).

I already shut down ppcoin, bbqcoin, geistgeld and terracoin to save some RAM, and that was with all of them being daemons not qt-GUIs.

-MarkM-

Welcome to the hallowed ranks of devtome authors!

Devcoin exchange rates have started to recover already, you must have a huge fan base!

-MarkM-

What, visa has two paid devs?!?! Cheaters! No wonder they're ahead of us. No fair!

-MarkM-

Ok but that doesn't address money/currency velocity at all.

-MarkM-

Often if you buy off the rack / rackspace-ilk hosting, the number of connections the webserver is configured to allow to the mysql database does not match the number of connections the database is configured to allow.

When traffic increases, sometimes people end up only increasing one of those sides of the thing.

Entry processes sounds vaguely familiar as maybe relating to such situations.

Maybe though it might also relate to connections you try to make to another machines to talk to your coin daemon.

Like maybe your webserver, or the host running it, has some limit on outgoing connections. or the coin daemon's machine has some limit on incoming ones.

Its not really clear to me what layer is telling you there is a problem, like is it something the webserver is saying, or something mysql is saying, or something the operating system on one of the machines you are connecting between is saying.

20 connections seems a puny number to cause a problem, whatever layer is having the problem.

Oops, wait... I mean, setting your limit to 20 seems crazy low, who set it that low and why?

Aha, the shared hosting, likely! DIrt cheap hosting? Maybe even free like in my .sig ?

(Actually I think the free hosting in my .sig might not have that low a limit, I think where it starts to bite is only 5 gigs of bandwidth per month. Oodles of nice stuff, but put any eyecandy on it and you'll go over 5 gigs a month with not a lot of regular daily visitors...)

-MarkM-

Ah, okay, got you. If that tourist had wanted to buy all the services all the villagers had managed to sell to each other with his money while his back was turned, it would have cost him a heck of a lot more money than just that one "coin" they used for a few minutes behind his back and returned to him.

-MarkM-

Its not just RAM, its screen image, which can be scraped by keylog-and-screensrape malware; its keyboard and mouse input, which can be pirated by keylogger and mouse-emulator malware.

Its a massive attack surface best done without.

-MarkM-

The "spec" was not self-consistent, because on one hand it claimed blocks are a max of so many bytes yet it also claimed blocks of that many bytes only ever need a max of 10,000 BDB locks, which turns out to be false.

So, it was an incorrect / invalid / buggy / mis-specified / inconsistent "spec".

If we turn it into a human-readable spec, it should be read as blocks are at most one megabyte in size and the programmers working on the implementation should ensure that all details of the implementation are such that there are enough widgets / whatzits / whatevers provided (heap space, array size, whatever, locks if your database happens to use locks, etc etc etc) for blocks of that size to work.

Turns out that if you happen to use BDB for your persistence layer, you need more than 10,000 locks. Ooops.

-MarkM-

Whoa, explain how velocity increases exchange rates?

Surely velocity means the same coin can be used by more people in less time?

So more people manage to get their greek village parable circle of trade to go round with less coins.

So they don't need to buy as many coins per village.

How does that increase exchange rates?

-MarkM-

Weird, 0.8 uses leveldb not BDB doesn't it?

Does leveldb use those same calls to set its configuration?

-MarkM-

I merged-mine lots of chains, all using the same merged-mining patch I think, though I am not sure if i0coin also uses the same patch. (I think it does though.)

Could it be that i0coin tries to validate blocks even before reaching the most-recent checkpoint?

I don't know if older versions of bitcoin did not skip over all the blocks up to the last checkpoint, only checking that the block-hashes of the checkpointed blocks matched its list, and only doing real validation of blocks more recent than the most-recent checkpoint.

Another weird thing about i0coin is it dies from failure to do a DNS lookup, I think it tries to look up a timeserver for some reason, and uses DNS instead of IP address to do so, and thus dies when my connection is congested or flakes out or whatever, causing DNS to fail. No other coin (and I have run a lot of types of coin) has ever done that as far as I recall.

-MarkM-

So, K1773R, a memleak, you said? In confirmation code somewhere?


Can you be more specific about where, or what it is leaking, or anything similarly potentially-helpful?

It used to eat twenty-something percent of my RAM, then on a recent restart suddenly its eating close to forty percent, and I am not aware of any particular activity going on that might account for its "sudden" need for twice as much RAM as it had been using for past few weeks or months.

-MarkM-

There is a max number of inputs and/or outputs a block of a specified size could possibly contain, so that, plus the number of transactions it itself contains, bounds the number of transactions it could possibly touch. Double that to account for needing to process two blocks at the same time when doing a re-org. Then add some fudge factor, or double again or something, to account for any margin of error you think your calculations might have.

Hopefully the configuration even lets you specify the page size you want BDB to use, so that you don't have to know the block size of the underlying block-device in order to do these calculations.

As to being arsed, it is only an experiment and only involves less than a billion dollars or so so yeah, time enough for that when the experiment has determined whether there is any point in building a real implementation of something along the lines of what the experiment is attempting.

-MarkM-

Please explain how you reach that conclusion?

I thought velocity of money/currency is how fast it gets spent again and again and again, so that the more times per [span of time] the same coin can be spent again the less coins in total the system needs.

For example, if velocity was 21 million per day, so that one coin was being re-spent over and over 21 million times per day, then one coin could do the job that would have taken 21 million coins to do if velocity had been only one spend per day?

How does that cause deflation?

On the other hand if adoption increases while velocity does not increase as fast as adoption does, then there would be more need for coins / need for more coins, which sounds like it could be deflationary.

-MarkM-

So java is bloatware compared to C ? This is news?

Or could the java have been written as concisely without loss of efficiency?

-MarkM-