Bitcoin Forum
September 28, 2016, 06:52:11 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: [PATCH] increase block size limit  (Read 43334 times)
Technomage
Legendary
*
Offline Offline

Activity: 1568


Next Gen Physical Bitcoins - Denarium.com


View Profile WWW
February 26, 2013, 01:51:56 AM
 #41

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.

Denarium - Leading Physical Bitcoin Manufacturer - New Gold Plated coins in stock!
1475045531
Hero Member
*
Offline Offline

Posts: 1475045531

View Profile Personal Message (Offline)

Ignore
1475045531
Reply with quote  #2

1475045531
Report to moderator
1475045531
Hero Member
*
Offline Offline

Posts: 1475045531

View Profile Personal Message (Offline)

Ignore
1475045531
Reply with quote  #2

1475045531
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475045531
Hero Member
*
Offline Offline

Posts: 1475045531

View Profile Personal Message (Offline)

Ignore
1475045531
Reply with quote  #2

1475045531
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2422


View Profile
February 26, 2013, 02:06:04 AM
 #42

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 26, 2013, 09:23:54 AM
 #43

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.

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.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Akka
Legendary
*
Offline Offline

Activity: 1064



View Profile
February 26, 2013, 09:27:55 AM
 #44

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.

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.

All previous versions of currency will no longer be supported as of this update
poly
Member
**
Offline Offline

Activity: 84


Weighted companion cube


View Profile
February 26, 2013, 11:56:47 AM
 #45

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.

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.

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.

poly | My Tip Jar
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
February 27, 2013, 05:51:02 AM
 #46

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

https://bitcointalk.org/index.php?topic=145224.0

Syke
Legendary
*
Offline Offline

Activity: 2016


View Profile
February 27, 2013, 06:08:06 AM
 #47

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

Buy & Hold
Rogue Star
Member
**
Offline Offline

Activity: 88


View Profile
February 27, 2013, 06:52:03 AM
 #48

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.
what you are really saying here is:
Quote
S.Dice are transactions. Increasing the block size to support transactions is absolutely the wrong idea. Bitcoin cannot be built around transactions.

Most people around here are thinking about transactions incorrectly. I'm going to single out Jeff in passing because he is a core-dev that has only gone from one extreme to another. Bitcoin is not built to support micro-transactions and this is evident from the way transactions must propagate and all the economic incentives that support the auditing of transactions. What is not evident is what a "micro" transaction really is in the context of Bitcoin.

I think fundamentally a micro transaction in Bitcoin is a transaction or perhaps a tx out that is not worth propagating or auditing. Technically it is very hard to argue S.Dice is a micro transaction otherwise it would be impossible to propagate or audit. Economically it is not so clear cut, but there is a market for auditing S.Dice transactions, so I would say economically it is not a micro transaction. You can say that S.Dice is subsidized by the block reward, but take the reward away and it almost the only incentive to audit other transactions. Thus, S. Dice will not truly be a micro transaction in the context of Bitcoin until it is impossible to transact on the Bitcoin network. When that will happen will be determined entirely on network management.

Bitcoin never promises to support micro transactions as I've outlined it nor is it built for that. Bitcoin is a payment network. From a network management point of view S.Dice is a problem because of the spammy messaging, but otherwise the transactions are just as valid as any other on the network.

My network management suggestion to S.Dice would be to include the messaging component as part of the bet so the messaging output would be limited to the size of the minimum bet, which should follow whatever the network can support. Integrations with wallets such as blockchain.info could just hide the messaging component of the bet to make it user friendly, done correctly it could even be used to collect any dust it has already created. Perhaps it is also worth considering not using a messaging component for most S.Dice bets as it has already established a reputation and messaging could be implemented as an optional value-added service rather than a default operating mode.

you can donate to me for whatever reason at: 18xbnjDDXxgcvRzv5k2vmrKQHWDjYsBDCf
ArticMine
Legendary
*
Offline Offline

Activity: 1722


Monero Core Team


View Profile
May 31, 2015, 06:00:24 AM
 #49

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time.  Sad

Concerned that blockchain bloat will lead to centralization? Storing less than 4 GB of data once required the budget of a superpower and a warehouse full of punched cards. https://upload.wikimedia.org/wikipedia/commons/8/87/IBM_card_storage.NARA.jpg https://en.wikipedia.org/wiki/Punched_card
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 31, 2015, 12:28:24 PM
 #50

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time.  Sad

Yep, and I would really like to see Jeff Garzik explain what his solution is now since he has had 4.5 YEARS to consider it further.

A solution other than do nothing, lets crash into the limit (which he never liked in the first place), and see what happens.

More like this maybe:

We should be able to at least match Paypal's average transaction rate...

Code:
-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+ TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;

samson
Legendary
*
Offline Offline

Activity: 1078


View Profile
May 31, 2015, 05:55:06 PM
 #51

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.
HCLivess
Hero Member
*****
Offline Offline

Activity: 938


If you want something too bad, it is overpriced


View Profile WWW
June 01, 2015, 10:55:31 PM
 #52

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.
hard fork

100% new code, 0% premine, 0% ICO, 0% dev rewards, Python, easy integration https://bitcointalk.org/index.php?topic=1525078
_biO_
Full Member
***
Offline Offline

Activity: 164


View Profile
June 02, 2015, 06:12:13 AM
 #53

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

The problem is that you can't react to a large increase immediately, you need at least 6-12 months lead time or you risk a fork. Also, the default blocksize soft-limit is actually 750k, which most miners adhere to. So were are at ~66% of the preconfigured capacity, on average. If usage increases, as it historically does during winter, we might have serious capacity problems next year, and we maybe even see the signs this year. Especially during peak times we might see an substantial increase in confirmation times that may drive users away from bitcoin.

This signature refers to itself.
bitcreditscc
Hero Member
*****
Offline Offline

Activity: 588



View Profile
June 02, 2015, 07:58:15 PM
 #54

Fanboys spouting shit should read this thread. The change to larger blocks has been in the works for a long time so buck up and lets do this.

Morecoin Freeman
Hero Member
*****
Offline Offline

Activity: 588


Legendary trader


View Profile
June 02, 2015, 08:07:32 PM
 #55

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

Ask the stranger he knows who you really are.
Pecunia non olet
Full Member
***
Offline Offline

Activity: 210


I DGAF


View Profile
June 02, 2015, 08:14:19 PM
 #56

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

That can be read on various places. Please search the web before asking questions that have been answered 100 times already.
Morecoin Freeman
Hero Member
*****
Offline Offline

Activity: 588


Legendary trader


View Profile
June 02, 2015, 08:30:16 PM
 #57

Ah excuse me, I guess you are right. I did read something about it just now.
In case someone else has the same question, what I found:

That it could lead to centralization within the mining community, which would favor bigger and richer mining operations.
And that there are too many unknowns about the consequences of increasing the block size to 20 megabytes.

Ask the stranger he knows who you really are.
bitcreditscc
Hero Member
*****
Offline Offline

Activity: 588



View Profile
June 02, 2015, 08:45:37 PM
 #58

That is all moot. Just think, your phone can get a 128GB memory card. Your HDD can be up to 4 TB right now. Where does it seem like the average user cannot keep up?

just because we say teh max block size is 20 MB does not mean we will immediatley fill them. likely the'll remain around the same size for a bit longer before they regularly pass the 1 Mb size, they likely wont touch 2 Mb average for another two years.

In terms of storage within a year 10 TB, 20 TB and 50 TB hard drives will be commercially available, so i see no reason to hold back progress over baseless fears.

bitcreditscc
Hero Member
*****
Offline Offline

Activity: 588



View Profile
June 02, 2015, 08:46:42 PM
 #59

People have no problem downloading GTAV or MKX yet they cant spare 50Gb for their money. Let's be serious people.

Morecoin Freeman
Hero Member
*****
Offline Offline

Activity: 588


Legendary trader


View Profile
June 02, 2015, 08:52:06 PM
 #60

I am somewhat uneducated on the matter, but I would also opt for the change in block size limit.

Ask the stranger he knows who you really are.
Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!