Topic: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... - page 14. (Read 105069 times)

Have you read all post from this thread? The "much disk" will not be needed! We have blockchain pruning.

The dominance of large mining pools is not due to the cost of running a node. There are thousands of full nodes, and yet the top 4-5 pools direct the majority of the network hashrate, as you note. The reason large pools have high hashrates is that pool size reduces the payout variance to miners, so miners prefer to use large pools.

So you need to be clear what you're trying to solve, and what is the cause of the problem. Because keeping the block size at 1 MB forever is not going to reduce the dominance of mining pools.

Well another grate post of D&T

I am not a big fan of increasing the Blocksize to 20MB

Having said that.

We see a huge concentration in mining environment 4-5 hands control 75%+ of mining power (Pools and Large Ops)

If the Blocksize increase exponentially the numbers or nodes may drop in a significant way just because they require to much disk, actually the network increase but there are not so many full nodes (nodes sharing the blocks)

With centralized mining and few nodes Bitcoin will be weaker.

I understand the reasons of Gavin A. to increase the Blocksize but we need to find a solution for the problem and an analysis that includes all the players in the Bitcoin ecosystem.

Lately I read many times that "The value is in the Blockchain" is true but without truly decentralized mining and a huge nodes constellation in line with the P2P Crypto Decentralized there is no Blockchain or Bitcoin (as currency)

Core Developers are a crucial part of all this, but also miners invest lot of money (more than all the VCs combined) and nodes add really decentralization to the system, we need an improvement that will generate more miners (not pools) more nodes and a healthy Bitcoin Network.

Regards

Juan

How do we decide what level of security is "required" for the network? What amount of hashing, what $$ spent on mining hardware... Is there a knowable, correct, answer?

Available hashing power must provide more reward when used to gain transaction fees than attacking.... right?

How do we know that existing coin minting even does this? (apart from it vaguely seeming like a very large amount, and no attacks really having happened)

Thank you for this interesting resumé D&T, always enjoy to read your posts, they were very helpful since the early days to understand the inner workings of the technology better. I am convinced   

The limit wasn't part of Satoshi's original plan, but keep in mind that the original plan was at that time very much a work in progress.  I was only involved for about a month back then.  When Hal and Satoshi started talking about involving more people, I dropped it.

Are you saying that the original plan was to have no limit at all? What would happen if we were just to remove the limit now, instead of making it bigger?

Gavin is right, we should do this now before its too late.
Heres a video for noobs that explains it quickly:
https://www.youtube.com/watch?v=U1KNbgoF-ZY

For what it's worth: 

I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code.  Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea.  Both Satoshi and I objected that it wouldn't scale at 1MB.  Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed.  The 1MB limit was there by the time Bitcoin launched.  But all 3 of us agreed that 1MB had to be temporary because it would never scale.

Several attempted "abuses" of the blockchain under the 1MB limit have proved Hal right about needing the limit at least for launching purposes.  A lot of people wanted to piggyback extraneous information onto the blockchain, and before miners (and the community generally) realized that blockchain space was a valuable resource they would have allowed it.  The blockchain would probably be several times as big a download now if that limit hadn't been in place, because it would have a lot of random 1-satoshi transactions that exist only to encode information for altcoins etc.

At this point I don't think random schmoes who would allow just any transaction are getting a  lot of blocks. The people who have made a major investment in hashing power are doing the math to figure out which tx are worthwhile to include because block propagation time (and therefore the risk of orphan blocks) is proportional to block size. So at this point I think blockchain bloat as such is no longer likely to a problem, and the 1MB limit is no longer necessary.  It has been more-or-less replaced by a profitability limit that motivates people to not waste blockchain bandwidth, and miners are now reliably dropping transactions that don't pay fees. 

Double the max blocksize every two years which roughly keeps in line with Moore's law.

Great post Death&Taxes.

However I have never heard anywhere people supporting to keep permanently the max block size to 1MB. So your post is somewhat misleading and is avoiding the most interesting questions. Which are:
1) max block size design : is switching from hard coded max block size 1MB to hard coded 20MB the smartest way to proceed ?
2) timing: is now the best timing to do that? It  appears there is no real argument to rush. Tons of innovation is going on, we are months away from a first side chain implementation. Perhaps in 6 months or a year from now we will have ideas we hadn't thought of.

From the comments here and on reddit, I don't see a real consensus on that subject. So imo it's better to keep discussing about it. We can reasonably expect to see concurrent proposals to Gavin's, with a different MBS design and perhaps a more appropriate timing.

I agree, and I never meant to suggest otherwise. Bitcoin still has effectively no block size limit, and if the block limit became 1GB tomorrow it most likely wouldn't result in blocks being any larger in the foreseeable future. I corrected myself because I at first said that no block limit would result in the greatest overall transaction fees being paid, but I don't think that's true. Given the tragedy of the commons issue surrounding blockchain size, the marginal cost of any individual miner including a transaction in his block is only negligibly higher than the risk of an orphaned block. If a miner doesn't include the transactions with fees above that marginal cost, they can be profitably taken by the next miner to create a block. That's not necessarily how it has to work, miners may attempt to employ strategies (like you mentioned) where that wouldn't be the case, but there's no guarantee they would succeed.

Great effort in posting. You hit the hammer right on the nail. But i think the title is slightly misleading for me. Perhaps a question mark at the end instead would suffice. I think a decision has to be made immediately because we are really close to reaching the limit with the current 1MB restriction.

+1 At that point we'll have a ton of sidechains (hopefully) that can handle any further growth in demand for peer-to-peer electronic cash transactions.

Gavins proposal automatically scales 40% per year after the 20mb raise, then stops after 20 years - last time I read up on it.

After 20 years this puts us at ~16.000 mb or 32.000 TX/second. That's more than the VISA network and I think it will last a long time.

I also support Gavin and OP.

So basically a solution should

- increase the block value (~20Mb)
- use high speed super nodes (in order to propagate in 2 minutes interval)
- use some kind of multi-threaded P2P protocol
- increase the reward on miners.

good.

what next ?

Blocks are just transaction data which has almost all already been relayed through the network. All that one has to send is just a tiny set of indexes to indicate which of the txn in circulation were included and in what order  and there are already alternative transports that do this (or even less-- just a difference between a deterministic idealized list and the real thing).  The data still has to be sent in the network, so it doesn't fundamentally improve scaling to be more efficient here (just a constant factor), but it gets block size pretty much entirely out of the critical path for miners.

bigger pools already use another block propagation between themself. i am not sure how much it can handle, but obviously its optimized for miners needs

In the end, the whole block of transactions must be present on the blockchain at the most distant end of the network in 3 minutes to allow newly discovered blocks to be added upon it. Ideally, you need to transmit 20MB data in 1-2 minutes. Maybe it is possible to use multi-threaded P2P downloading to accelerate the data transfer