Technomage
Legendary
Offline
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
|
|
February 26, 2013, 01:51:56 AM |
|
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 closing sale discounts now up to 43%! Check out our products from here!
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5348
Merit: 13314
|
|
February 26, 2013, 02:06:04 AM |
|
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
Activity: 1106
Merit: 1004
|
|
February 26, 2013, 09:23:54 AM |
|
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.
|
|
|
|
Akka
Legendary
Offline
Activity: 1232
Merit: 1001
|
|
February 26, 2013, 09:27:55 AM |
|
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
Activity: 84
Merit: 10
Weighted companion cube
|
|
February 26, 2013, 11:56:47 AM Last edit: February 26, 2013, 01:27:26 PM by poly |
|
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.
|
|
|
|
|
Syke
Legendary
Offline
Activity: 3878
Merit: 1193
|
|
February 27, 2013, 06:08:06 AM |
|
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
Activity: 89
Merit: 10
|
|
February 27, 2013, 06:52:03 AM |
|
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: 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
Activity: 2282
Merit: 1050
Monero Core Team
|
|
May 31, 2015, 06:00:24 AM |
|
Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;allEdit: 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.
|
|
|
|
solex
Legendary
Offline
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
|
|
May 31, 2015, 12:28:24 PM |
|
Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;allEdit: 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. 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... -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
Activity: 2097
Merit: 1070
|
|
May 31, 2015, 05:55:06 PM |
|
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
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
June 01, 2015, 10:55:31 PM |
|
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
|
|
|
|
_biO_
|
|
June 02, 2015, 06:12:13 AM |
|
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
|
|
June 02, 2015, 07:58:15 PM |
|
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
|
|
June 02, 2015, 08:07:32 PM |
|
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
Activity: 882
Merit: 102
PayAccept - Worldwide payments accepted in seconds
|
|
June 02, 2015, 08:14:19 PM |
|
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
|
|
June 02, 2015, 08:30:16 PM |
|
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
|
|
June 02, 2015, 08:45:37 PM |
|
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
|
|
June 02, 2015, 08:46:42 PM |
|
People have no problem downloading GTAV or MKX yet they cant spare 50Gb for their money. Let's be serious people.
|
|
|
|
Morecoin Freeman
|
|
June 02, 2015, 08:52:06 PM |
|
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.
|
|
|
|