Topic: [PATCH] increase block size limit - page 2. (Read 89775 times)

Which is why I started this thread, but have had no useful feedback:

https://bitcointalksearch.org/topic/will-50-btc-and-deepbit-move-to-version-2-blocks-145224

That is pretty much what is happening already with block versions now.

There's block version 1 and block version 2. When 950 of the last 1,000 blocks are version 2 or greater, all version 1 blocks will be rejected by those who updated, and will therefore be orphaned.

Could it not be simply introduced, that miners with the patch "mark" their blocks somehow and as soon as say at least 80% of all blocks are "marked" a countdown activates (maybe 20,000 Blocks) to give the remaining 20% some time.

Of course they shouldn't be "disallowed", but regardless of what they represent elsewhere, these dust transactions may be a "nuisance" to Bitcoin if they are not majorly composed of fees.

I don't understand why using Bitcoin for this inherently centralized use cases (like asset issuing), when there are better suited protocols like Open Transactions, for instance.

When Satoshi introduced the backward-incompatible checksum change, he set it to activate after two years. That seems like a reasonable amount of time.

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

Thanks. CVE-2012-4682 is dated 14-Sep-2012.  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4682. That is less than six months ago. This means that six months is the barest of minimums if at all. A much more reasonable time frame is 12-18 months or even longer.

About half maybe

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124682

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

True. I think that a plan must be figured out within the next 6 months if we don't want to rush the hard fork when it's time. And hard fork is such a thing that we don't want to rush it.

It's not that bad though. They can simply put rules in place for the nodes so that the fork only happens when a sufficient number (maybe 90%) has upgraded. Then it's up to the users how fast the hard fork happens. It can happen quickly if the fees become a problem, simply spread the word.

Based on the 10x growth of the number of Bitcoin transactions over the last year that places the issue under a year away. The problem is that it can take a year to do a hard fork properly.

I don't see the urgency, so it's more like a snooze button than a wakeup call.

We immediately put in a block number at which max block size will be read from the config file instead of being hard-coded into the code.

Then sit back and yack until what actual number to put in that spot in the config file becomes clear.

-MarkM-

I just checked. We're currently at 0.7 transactions per second. If it can scale to 7 transactions per second, well, we still have a long way to go before we even start to have truly crowded blocks.

As important as this issue will eventually be, it's not worth it to get too heated about it at this point. Even when the blocks start getting crowded it's not an immediate issue, fees will simply go up a bit which is not a big deal since the transactions are currently almost free.

How does this address a critical part of Satoshi's post namely that this be implemented "... in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete"?

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.


There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)


It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees. If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

Sane "colored coin" or "smartcoin" protocols don't depend on some fixed "1 satoshi = 1 share" ratio. Rather for each transaction moving an asset around they calculate what fraction of the asset was assigned to what transaction output, which means you can divide the asset indefinitely without requiring the actual amount of Bitcoins to change. If the asset represented by a txout is worth less than the minimum transaction fee, it's still dust that doesn't make sense to spend.

It's unfortunate that the first smartcoin-type protocols weren't written that way; on the other hand none of them have actually been used in practice. I've written a protocol that does this correctly as apart of my fidelity bonds protocol, see here although I haven't written code to implement it yet.

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

A tiny fraction of a bitcoin might represent an ounce of gold (for instance), and so it should NOT be assumed useless or disallowed by the protocol!

I think prioritizing transactions by fees is better than trying to rule out transactions which don't have an immediately obvious purpose.

Speaking of, you made a "dust-spam non-standard" patch right? Where is it?