Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.

So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough to need more locks than the BDB had been configured to permit.

-MarkM-

I was told on #bitcoin-dev that actually the devs have met the BDB configuration numbers before, and to look at db.cpp to see where in the bitcoin code they explicitly set the numbers they want BDB to use.

Also, they they ran into problems with it before.

So supposedly they were not unaware that BDB can be configured. They even confided that the page size BDB uses is by default the block size of the underlying block device (the disk drive, for example).

So from the sound if it they simply had not set the configuration numbers high enough to accomodate all platforms, or maybe all possible sizes of blockchain reorganisation. (During a re-org, apparently, it needs enough locks to deal with two blocks at once in one BDB-transaction?)

-MarkM-

For one thing, a GUI client needs a GUI, which is a massive amount of overhead for machines that have no screen, no mouse, and no keyboard...

-MarkM-

Whats the problem? Its a vapourware organisation, FT mentioned a specific item of vapourware it'd be nice to have, all good so far...

-MarkM-

He is telling us what we should, in his opinion, do.

We don't have to do it.

-MarkM-

Huh? Him exercising his freedom to spam and me exercising my freedom not to include his spam in blocks I create, or even not to pass them along to my neighbors, is extortion?

Or him extorting from me, by spamming, the coding-minutes it'd take to filter him out is extortion?

-MarkM-

If "they" wanted to maybe "they" could claim that just like the source code is the specification, so also is the source code the contractual agreement through which the authors of that "contract" direct and order and control the distributed operation of [such a venture] ?

To what extent do "they" get to just [kill anyone Obama says is a terrorist / do WTF they choose ] ?

-MarkM-

On first read I don't see any obvious problems with it.

Hopefully Mike Hearn will give some feedback on it.

-MarkM-

The natural value of bitcoins should be way the heck higher than it is right now, so yes litecoin too is undervalued.

Take a look at http://galaxies.mygamesonline.org/digitalisassets.html

MBC etc should never have been able to catch up to bitcoin in value, let alone surpass it. Bitcoin should go back to being the top dog on those charts, but doing so means it needs to more than double (up near triple) in value. Which it darn well should, it is really really absurd that it ever dropped below the others that are near the top of those plots.

-MarkM-

This chain has been humming along nicely lately, not a very high difficulty and you can merged-mine it so what the heck eh.

There are not enough reasonably well behaved merged-mine-able coins in existence to really see how many one could reasonably mine at once, but this one seems well-behaved so it doesn't hurt to include it in the merge.

(i0coin on the other hand tended to eat 20+% of my 8 gigs of RAM and since yesterday is for some reason now eating about 40% (40+% yesterday, 39.9% right now).

-MarkM-

Look in db.cpp

There are three settings related to locks, see

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

If increasing one of them to 40,000 from 10,000 is it really okay to leave the other two unchanged?

-MarkM-

Unfortunately from the small amount of observing I did on #bitcoin-dev last night, Jeff seemed to not get consensus maybe a little too often to take the reins.

However that might just be an artifact of his not being the lead developer thus being more free to [seem to] espouse positions that aren't at that moment the clear consensus.

As I don't know whether it was such an artifact though, I'd have to say from that brief span of observation I'd have had to choose Gregory, at least during the duration of the "emergency".

If Luke was in charge at the Vatican maybe it would be policy there to always take at least two years to appoint a new pope!

So lets wait at least 2 years before putting him in the poll! Hahaha.

-MarkM-

Not adjusting the difficulty is broken.

Liquidcoin doesn't adjust difficulty. It results in faster and faster and faster blocks, colliding with each other, almost all becoming orphans, the orphan rate climbs instead of the difficulty climbing. Ugly mess.

So forget not adjusting difficulty.

Giving me free coins just for being connected is fine, I'll take them. If you wanna send me some BTC, NMC, DVC, GRP, IXC, I0C, CLC while you're at it (you can merged mine them alongside Capcoin if you make Capcoin merged mine able) I'll happily accept them too. Heck you're welcome to send along some GeistGeld, PPCoin, Freicoin while you're at it, heck anything you got!

-MarkM-

I think the job meant was pool operator, not miner as in, often enough, a mere hasher who does not even see the blocks being hashed. Such "miners" are more like bank tellers or even just folks who host an ATM machine for profit than actual bankers.

-MarkM-

I still think that sitting around all day doing pretend transactions, even if doing it on salary, isn't very motivating. Though maybe with a huge enough salary it could be rendered somewhat tolerable.

That is why I have always leaned more toward the approach of doing it with real "play money" - "real" play money - game money.

The big problem with the testnet for that is the restarts. Players don't like to know all their hard-earned game-money is going to vanish poof gone any time the developers decide to do a restart.

Get a bunch of players using a bitcoin clone for their game currency though and maybe you could build up a large motivated bunch of people who will happily do all kinds of imaginary commerce, lots of transactions, maybe even try to do doublespends against enemy nations' transactions, maybe try for 51% hash power to block enemy nations' blocks completely, all kind of fun stuff.

For example we could apply the merged mining patches to bitcoin 0.8, add a -playnet flag to commandline and config file that activates the merged mining as a secondary chain capability so we could even do it in merged mining mode as a secondary chain, have that flag also change cosmetics such as the name of the coin and its logo and favicon and such, its data directory, its config file. Presto, a playnet alongside the testnet, a playnet that lets players derive motivation from the idea their playcoins are not intended by design to be ripped out from under them at any moment like happens on testnet.

The code needs all those cosmetics such as the name of the coin, its datadir, its IRC channel, its handshake, its ports and so on to all migrate to one easy to find place anyway so the ever growing number of altcoins don't each have to waste time getting directly to the nitty gritty details that make the code run as this that or the other Crunchy Berry Coin of the Day.

Basically the easier it is for altcoins to use the latest bitcoin code, the better such altcoins will be able to serve as testnets, playnets, cornercasenets, edgecasenets and so on and so on; new features can be deployed first in some playcoin or other - a real playcoin, not a vanish gone up in smoke coin like testnet coins are - for some heavy real-play workouts and shakedowns and burn-ins before deployment to the Serious Real Money bitcoin chain.

This is the same stategy I am using for Open Transactions testing and development: use it first for some real game trade and commerce and finance, for real, to see that it all works and load-test it and so on.

-MarkM-

Hmm, strange... Maybe the original post-er isn't aware of #bitcoin-dev on Freenode IRC?

Or is it just that not enough of the VIPs the OP would like to see hang out there actually do hang out there?

-MarkM-

0.8 had all along been saying, over and over, as part of its response to any RPC command, not to use it for mining nor for commerce.

So hey, its not like its users hadn't been warned, constantly, nagged even.

But the 0.7 GUI users types aren't used to "oh gosh looks like upgrading time has come" messages being of a "upgrade right this second or the sky will fall" urgency.

So on balance, it maybe makes sense to prove to the 0.8 users that the nagging was there for a reason instead of freaking out all the drones who like their shiny GUI to be patient and nice about asking them to please someday think about maybe upgrading sometime, maybe even sometime relatively soon, if that isn't too inconvenient, thank you kindly.

-MarkM-
 

It was 0.8 that made, and found perfectly good, the block that caused the fork.

Some builds of 0.7, on some platforms, used implementations of Berkeley DataBase that crapped out trying to process the block.

Unmodified 0.7 nodes would never have produced such a block, which is why during the 0.7 era it was never noticed that a perfectly valid block could crap out some builds / implementations / configurations of Berkeley DataBase.

0.8 Does not use Berkely DataBase for that data (thought it does still use it for wallet.dat if I recall correctly but that is not the DB that crapped out) so it too would never have noticed this problem some cases of BDB exhibit on some platforms.

-MarkM-

Thank you. I do not think I am actually far afield from Gavin, as I am pretty sure I have read him and/or other core devs discussing blockchain validator tools each of which would validate a certain range (by "height") of blocks.

In other words, no time machine going back and changing the historical past, just no repeating of the errors of the past in the future.

Basically the spec that tells us certain configurations, versions or implementations of BDB are not up to spec would be the spec for the new thing, the Real Bitcoin. The fact that the Satoshi node wasn't up to that spec gets enshrined not in the historically non-normative block-creation spec/code going forward but, rather, in the normative "validate a certain period of blockchain history's blocks" blockchain-checkers that I read some core devs discuss once upon a time.

An RFC could comment on details where certain builds of the Satoshi client on certain platforms failed to meet the new thing spec, and block heights could be targetted for the block height at which such builds will be orphaned, unsupported, deprecated, unable to function as part of "the Real Bitcoin" aka the new thing from that point on.

This is all old news / old ideas to Gavin et al I am pretty darn sure, which is why I am not in a panic over block sizes nor was in a panic yesterday evening over certain builds of Berkely DB on certain platforms in certain builds of the Satoshi node failing to perform to [ex]spec[tation].

So nyah nyah nyah circle jerk time group hugs for the geeks and techies, sorry if the PR folk aren't into that.

-MarkM-

Lets drop the bug for bug compatible idea too while we're at it.

Tolerate any existing buggy blocks over 120 blocks old or that predate the last hardcoded checkpoint or something but don't make a religion of emulating the bugs going forward.

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll them back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".

-MarkM-