Think "to throw out windows".

-MarkM-

I don't know, but I don't think bitcoin 0,8's code will fix it, as the limits constants inherited from bitcoin aren't any different from one version of bitcoin to another.

So if we can fix it, we can do so right away, with a fix to the current old-bitcoin-code based DeVCoin; no need to wait for some day when we get around to making a version of DeVCoin that is based on the 0.8 bitcoin code.

Basicically if we can figure out what number where in the code is preventing it from being processed into a block, we will then be able to check whether preventing it getting into a block is necessary; if it is in fact necessary we should fix the user interface (the RPC calls for sending coins, and whatever the GUI code to do it is in the GUI version) to prevent users from being able to do such transfers in the first place, so that they never get sent to the block building system in the first place.

I suspect the problem, at root, is that users are being allowed to [try to] send more than 21,000,000 coins at once.

Possibly we can also adjust the actual limit constant definition, which is probably currently set to 21,000,000 coins, to (maxint64/100000000) too, if that is so much larger than 21M that such a change is worth stepping away from the number 21M that coiners already have genetically coded into their expectations of maximum number of coins of a bitcoin-based / bitcoin-derived coin system.

-MarkM-

EDIT: As to actually losing the coins, probably if you double-spend them, that is, send them in batches of less than 21 million somewhere else, your new transactions might get into the chain, making the old one obsolete, leading to it being dropped from the memory pool. If that doesn't work without a fee, maybe adding a fee too could help if the block building code actually does prioritise transactions that have fees over ones that have lower fees or no fees. Whether clients tend to allow one to easily attempt such re-sends aka double-spends I do not know.

(That might be where newer bitcoin code might come in: maybe the old code we used does not have coin-control and does not have a raw transactions RPC call.)

No, because the hard limit is a hard limit on how large of a "little guy" they could push out, and that limit is, basically, guys so frikkin tiny that pushing them out gains so little the effect is lost in the noise of more not quite that extremely tiny guys coming online all the time.

Basically you can't kick out the little guy, given the current hard limit; you can only kick out the trivially tiny guy who isn't even worth the trouble of kicking out.

-MarkM-

Only if all the folk we are worried about clearly identify blocks they make as having been made by them.

Absent voluntary identifying of themselves who made a block is unknown, they are pseudonymous just like any other bitcoin-address.

And even if they do vokuntarily identify blocks they make that they want us to know were made by them that would not force them not to make any other blocks they don't tell us were theirs.

-MarkM-

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-

Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-

It is not even arbitrary in itself, once you already accept halving the block subsidy. It is simply an attempt to give the miners more space to sell to make up for lowering their subsidy.

Now if you want to argue that changing the subsidy over time is arbitrary, leading to the limit of 21,000,000 coins being arbitrary, well yes you've got me there. But, the actual total number of coins is irrelevant as no matter how many coins "100% of all bitcoins" happens to be it remains "100% of all bitcoins" so how many that is in various units of measure other than "fractions of the whole" it happens to be is kind of irrelevant (and making it look different cosmetically like calling it millis or macros or megas or picos or whatever is purely a user interface design issue).

-MarkM-

Once I get my free Ripples I will be able to start telling Ripple about all the various altcoins I would like to exchange for each other and for Ripples. That will just be a stopgap measure while I wait for the ability to flag an account as a "destination code required" account so that I can start trying to adapt the sample "web-based gateway between bitcoin and Ripple" code to other blockchain-based currencies.

Basically I am looking to issue Ripple IOUs denominated in the various coins my Open Transactions server already supports.

Hopefully those IOUs will help people to more easily exchange between those various currencies, however my model is more like e-gold or Pecunix than, say, MtGox or Vircurex or Bitparking. That is, the intent of the tokens/IOUs is to be long term 100% fully backed tokens backed by actual coins buried so deeply and securely in cold wallets that ordinary people are not expected to be causing the vaults to have to be dug up and dipped into on a day to day basis; rather, it is intended that market-makers buy and sell the tokens to help people get in and out of the markets.

Nonetheless if I can adapt the web-based-gateway code to alternate chains I might well end up running one of these market-maker type operations myself (a hot-wallet operator, basically) in addition to my token issuer operation (a cold (very cold!) wallet operator, basically.)

As to the specific currencies aka assets I already support in my Open Transaction server and thus hopefully will be able to also bring to Ripple, see http://galaxies.mygamesonline.org/digitalisassets.html

-MarkM-

Re sucking in more users, if it is precisely an increase in the number of users that threatens us with all these problems in the first place, maybe it is time that we stopped being so eager to suck in more users. We are working nicely so far with the users we already have. If more want in that is going to cost us a lot, so using freebies that cost the whole population of full nodes, including miners, a lot, precisely to attract more new users faster, does not seem that great an idea.

-MarkM-

If I recall correctly, pretty much the only, or at least the core, argument in favour of allowing any free transactions at all is as a propaganda / public-relations scheme to suck in more users. Basically a free loss-leader.

Aren't we getting to a point where anyone who wants to blow wealth on giving out free loss-leaders can do so themselves, simply by paying the damn fee themselves or lowering the prices of what they are selling by the amount of the fees involved in the actual selling of the thing?

For example, merchant terminals could add an input from their own float account to the transaction before presenting it to the buyer for signing of the buyer's input, or publish separately a transaction with fee that takes one or more recent payments of customers as input. (This latter though would make verifying blocks harder, since verifiers would not be able to tell whether a free transaction has sneaked into the block simply by checking whether the transaction contains a fee. So maybe free transactions are not yet being rejected by verifiers simply because verifiers are currently too simplistic to recognise cases in which the fee is being provided by a dependent transaction? We could however, make each block able to be verified as to its lack of free-riders by requiring any such method of providing its fee be in the same block.)

-MarkM-

It is also truly harmless, that is, utterly uneffective in influencing them in any way, to the big miners.

Sure it might impact miners who are too small to have direct dedicated high bandwidth pipes to the top 51% miners, but the top 51% miners will not even notice if every one of you irrelevant non-mining nodes all stick your heads in the sand at every block on the chain. You just don't matter to the big boys, the most you could do would be help the big boys to shake the small players out of the game faster.

-MarkM-

rpVft3wic2fZ2saY5BjEtL8R2NPrubxWG5

What are we supposed to be looking for in that block?

Presumably there is something about it that causes you to wonder; what exactly is it about that you are wondering about?

What exactly is it about 0.8 that you thing might not like this block?

-MarkM-

Okay but if you have somewhere in the neighborhood of three megaminers, of a scale about like one would get by Google buying deepbit, Paypal buying another, Amazon buying another, etcetera, Eligius either heaviliy sponsored by whatever coalition of bible-thumpers can add up to such scales or marginalised due to being actually trivially small in the new larger scale scheme of things, the only propagation that matters is the direct high bandwidth pipes between these superpowers. The 49% or less - the whole rest of humanity - gets a crumb from the superpowers' table less than 50% of the time and even within that demographic the bigger fish in that smaller pond can hook up directly to each other, and maybe even try to co-operate in finding sneaky ways to get more peeks faster at what the superpowers are actually working on in a given one block period, so quite possibly half or more of the 49% also are not affected by the relaying decisions of mere non-mining nodes.

Lets think for a moment of all those Jalapinos that once upon a time sounded like they could decentralise hashing power into every home. Are all those coffee-warmers going to have to be moved out from under livingroom or home-office coffeecups, co-located in data centres somewhere, if they are to be able to keep up with actually validating? They would, if they didn't actually validate, be merely rubber-stamping on behalf of someone else...

-MarkM-

Hmm, the one I remember was about enabling multiple-signature transactions, which judging by the apparent lack of the ability to do such transacti apparent lack of clents that secure you wallet by requring two signatures to spend from any of its addresses (the idea being you have one signing key on one device, one on another, to accomplish two-factor auth), seems like it was not afterall anywhere near as urgent as it was made out to be.

This block size thing is a slam-dunk, the only question really is how many of our hard-hoarded bitcoins are we going to have to blow on shiny new hardware to stay a full node or is the jump in size going to be too vast for any reasonable such expenditure to be "worth the candle". (Maybe just saying good-bye to bitcoin, leaving those hard earned coins to grow on their own in a cold wallet until one's retirement years, is a better play than playing at being involved in some way in the bitcoin space? Or maybe even cashing it out given the inability to ever actually verify its operation?)

So I am mostly concerned that the bigger is better, bigger is more exclusive, bigger decreases the number of competitors type of enthusiasm for sheer size for the sake of sheer size is going to slam dunk the max size way up into the only the Googles of the world can play scale, which it seems likely right now it is the plan to actually do. (Since no limit and infinite max size are basically equivalent. "Junk expands to fill all available space" or "junk multiplies to cover all available surfaces" is kind of a classic old saw, isn't it? Not sure it even comes from the housework field, which I think is where I first came across it.)

-MarkM-

And carrying out a 51% attack that much cheaper for attackers.

-MarkM-

How about a simple as Satohshi's reward-halving method?

Simply double the block size when you halve the block-reward size.

Voila, all done for the next 136 years, nice and predictable, plenty of time to prepare for etc etc etc.

-MarkM-

Miners like lots of paying transactions, but payment processors like lots of transactions that pay the payment processor, and if they can get those transactions into the blockchain without paying miners heck that is a nice bonus for them, is it not?

So it seems to me that outfits that make money by spamming as many transactions as they can into the blockchain, making their money on what they can charge whoever their customers are for either that spamming or the effects of that spamming or even the ultimate long term effects/results of that spamming, are another group of actors who stand to gain by the largest blocks they can convince miners to create. I am not sure whether they would also ally with miners in the forcing out of competing miners, but maybe if miners demand such co-operation in return for preference in getting into that miner's mined blocks maybe they would happily go along with it?

Mike suggested somewhere that one (such a one as Google, to give you an idea of the kind of one he is accustomed to) can handle massive numbers of transactions, even using commodity hardware (which Google is wont to do) by processing them with many machines in parallel, so no matter how many transactions pour in one can simply add more machines. Obviously for one such as Google, with their databases designed and proven for handling huge chunks (aka blocks) of data, handling large blocks is also not a problem.

So if we scale up to a point where only the Googles of the world are capable of keeping up, what does that buy us? Nice high value for our hoards of bitcoins, hopefully, but what else? And at what cost in terms of freedom, accountability and the like?

Maybe acquire deepbit while one is at it, maybe a couple of other pools? How many would one need to acquire, if even any at all, to reach a point where one's specialised ability to verify transactions, possibly accompanied by enough miner co-operation or aquisition of enough mining pools and/or ASIC fleets, lets you squeeze/force everyone else other than maybe Microsoft (would they even care?), Yahoo (would they?), Amazon (hmm they have a payment processor, would they maybe put up some resistance or be just another don't care?) Paypal/Ebay (would even they care, really? Isn't an unverifiable competitor better for them than a verifiable one, one whose work/transactions they are not a party to verifying better than one whose they are?) and so on and so on out of the business?

Why the heck did we ever want more than just the single most-equipped-to-do-it player on the planet to verify transactions, again?

Can we leave watching over them to backwards-looking approaches, maybe? Never be able to catch up to where the blockchain is actually at but with a fleet of accounting/audit firms on the job be able to determine within a few weeks or months of some slipup that a slipup has happened, leaving the last several weeks of the chain invalid with respect to all transactions downstream of some erroneous one the accountants eventually discovered?

What if that "error" turned out to be a failure of a large number of silk road's coins to arrive at silk road's wallet?

Etc... All this push toward eliminating more and more of the population's chance of being able to verify makes me wonder why the heck we ever cared about verifying anything in the first place? Can't we just let Big Brother take care of everything as he always did/does, maybe even trusting that if blockchain technology has any application in such fields Big Brother will make use of it on our behalves?

A skeptical / cynical little voice in me scoffs ha ha you'd be lucky to only be halved, more likely you'll be quartered or decimated or worse...

-MarkM-

s/the blockchain/the primary blockchain/

Also, I am pretty convinced we can double the max block size every eighteen months fairly safely, or if not that much then maybe increase it 50% every year, so I am really more on the lets do absolutely minimal increases to ensure normal consumer machines upgraded every five years or so can keep up side than the lets never increase even when the machines we pick up at the furniture bank for free see the entire blockchain as trivially small and 7G networks flood the city making internet free pretty much everywhere that isn't a total middle of nowhere wilderness/backwoods side.

-MarkM-