2011 block size sufficed for $32 exchange rates, we have not exceeded that $32 rate in all the time since, so obviously we have plenty of space still.

In fact, we don't even use the space we have, not even half of it maybe, so if using it all cannot get us up to $64 maybe we are throwing too much money into hardware and not enough into the actual currency itself?

Up at $64 or so maybe talking about possibly doubling the size might start to make sense, then again maybe it'll be a few more years yet before we have $64-bitcoin level of actual usage?

-MarkM-

Exponential growth in block size = happy megaminers = large/many transactions will be preferred and megaminers with find a minimum block size themselves based on the small fry's bandwidth and how long the small fry are willing to struggle to keep up with larger blocks before being successfully ousted from the business.

-MarkM-

Well maybe Unthinkingbit can cast some light upon it. He is the designer and basically the senior analyst, I mostly just coded/modified what and where he told me to code/modify and dealt with making tarballs, putting them online, setting up github repos and such.

I can't think of anything offhand to explain this problem, at a glance it doesn't even look like it is trying to make the balance of any one address go over 21M but then again I haven't looked up the current balance of each address it is trying to send to. Nor am I even sure the per address total balance even matters / is limited.

-MarkM-

Good! Now hold bitcoins, enough bitcoins that if exchange rates continue to grow as fast as people want the max block size to grow you'll not find the cost of the stuff you'll need to be a full node "unreasonably" expensive.

-MarkM-

That chain already has the majority.

But, a split *again* would occur when it got *back* to being longest, yes.

-MarkM-

Also, even though I would be surprised if I woke up tommorow to find that bitcoins had gone up to $1000 per coin, I would not be surprised if a whole lot of people's idea of how high a full-node bar could "reasonably" go suddenly jumped upward, maybe quite a bit.

So I think if the people who claim to "need" a larger block size limit to accomodate the lucrative large numbers of users they plan to bring into the system (but cannot bring in today due to the block size limit being in their way) put their "need" quantitatively into bitcoin by buying more bitcoins that could help a whole lot.

How much per bitcoin worth of people are you planning to bring in? Isn't it in your interest to hold lots of coins already yourself before bringing them in? Show how determined you are to bring them in by putting your money in the blockchain and quite possibly that will grease the wheels of upward blocksize movement quite a bit...

...And I have to admit, recent exchange rate trends do seem to indicate serious interest, and are every day making larger and larger upgrades of hardware and bandwidth look "reasonable"...

On the other hand, we hit $32 before on less transactions / smaller blocks than it is taking now to get there, so current levels don't really seem to compellingly call for more block size than we had last time we hit $32.

-MarkM-

And they are destroyed as they are spent on fees, the fees do not go to anyone such as miners etc. So the total number will go downward over time.

-MarkM-

Could it be a limit of no one address having a balance over 21M?

Maybe until the code tries to put together a block it cannot tell how much is "at" any one address, thus cannot even tell that an address is going to end up with more than the limit as its balance, while the code that does try to build blocks does check each address as it does so?

If that is the problem, then maybe we need to make sure the user interface does not have any problem displaying balances that are above that limit then let the block building code go ahead and allow the total balance "at" an address to be whatever it ends up being, since the blockchain does not store that it only stores inputs and outputs?

-MarkM-

Nah, generators can be bought or built, even ones that use wind or water instead of trusting the oill barons; and we can cobble together an IP network out of parallel port cables and serial port cables from igloo to igloo if we have to.

Or we can just buy our electricity and bandwidth from a different provider; plus we can audit/verify the number of kilowatt-hours we are getting, the quality of the alternating current's adherence to the number of cycles per second we ordered, and check that the blockchain our internet provider is giving us verifies and that the blocks it claims nodes out there somewhere are sending us verify. So we don't need to trust either of those providers, we can verify what they provide.

-MarkM-

I don't think we need more than the int64 on the blockchain.

Where we'd need more is any place that tries to add up all the inputs or outputs.

So actually even though the blockchain allows int64 per input/output, the code that adds up the total in and the total out probably also uses int64 currently, so the total of any one transaction is probably supposed to be limited; somehow though you managed to input a command to transfer more than 21M coins in one move and the input checking didn't check and tell you hey no way, too large a number.

-MarkM-

I don't think that is actually necessary, really?

What does your block 86425 look like and what is its hash? Is it actually different?

I think there is something other than those checkpoints that is causing connects to be dropped and so on.

I had a hard time just getting a second instance on my same machine to connect to my first instance. But finally after changing the order in which I started them up I got them to connect.

If you recall we did compare what block we were on etc, plus also I have recieved coins osmeone (maybe even it was you?) sent so it did seem we are both on the same chain, which should not even be possible if your block #86425 differs from mine.

-MarkM-

No, because bitcoin will never have more than 21 million coins.

DeVCoin has the issue because there is no actual real limit to how many DeVCoins there will be; it makes 50,000 more every block forever, so some day, I do not know when, should have more coins than can fit into the "int64 devtoshis" format used on the blockchain.

But, that just means no one transaction-input or transaction-output can have more than int64 devtoshis.

-MarkM-

You are proposing to sell income-earning / money-making "assets"? In short, "investments" or "business opportunities"?

Or is it just that by using an affiliate scheme, maybe even a multi-level structure of affiliates, you hope to attract affiliates who will try to earn money by selling your idea/product?

-MarkM-

One person told me one, in private message, that I use with -addnode. But that was in a private message, and my own node has no incoming port, sorry. Set yourslf up with an incoming port though and people should find you, and if they don't then give out your own node's IP and port for others to use -addnode to tell their nodes to reach out to you.

-MarkM-

0.8's blockchain uses 128 bit integers?

-MarkM-

Maybe the incentive is "multiply the fee your local (or trusted, or least-hated, or least-distrusted) blockchain-audit corporation charges you for consultations regarding the verity of the blackchain by the number of such consultations you expect to or want to make, and compare that cost to the cost of running a node so that you can audit it yourself"

-MarkM-

As I said really the limit is the use of int64 in the blockchain.

We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.

The constant set as 21M though maybe could be tuned up to maxint64/100000000.

-MarkM-

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

I also wonder what will happen when a user interface tries to tell aq user the total balance of a wallet or account if that wallet or account contains lots of addresses that each have the full 21M coins in them. I don't even know if doubles (double precision reals) are used for such displays and the addition that leads to them or if int64 is used there, a timebomb waiting to overflow the integer. I vaguely recall or have an impression that I had a cursory glance at it but I think I basically took it on faith from Unthinkingbit that it is the total per transaction/address that needs to be limited, the grand total of all coins in existence of in a wallet or account or whatever not being limited to using int64., Not sure though at this late date.

-MarkM-

Which boils down to is it or is it not a zero-trust system?

I suppose you'd argue it is a limited entry level zero trust system, a system that is zero trust for the megacorps and any sufficiently wealhy nations or other sufficiently well heeled players, but for normal folks is just another trust the big boys / trust the grownups / trust Big Brother system?

-MarkM-

Ten times the block size seems like scarcity is banished far into the future in one huge jump.

Even just doubling it is a massive increase, especially while blocks are typically still far from full.

Thus to me it seems better never to more than double it in any one jump.

If relating those doublings to the halvings of block-subsidy it too slow a rate of increase then maybe use Moore's Law or thereabouts, increasing by 50% yearly or by 100% every eighteen months.

It is hard to feel like there is anywhere close to being a "need" for more space when I have never yet ever had to pay a fee to transfer bitcoins.

-MarkM-