Bitcoin Forum
November 25, 2017, 04:38:23 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 [All]
  Print  
Author Topic: [PATCH] increase block size limit  (Read 84900 times)
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
October 03, 2010, 08:13:42 PM
 #1

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

Code:
diff --git a/main.h b/main.h
index c5a0127..c92592a 100644
--- a/main.h
+++ b/main.h
@@ -14,7 +14,10 @@ class CBlockIndex;
 class CWalletTx;
 class CKeyItem;
 
-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;
 static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
 static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
 static const int64 COIN = 100000000;

URL: http://yyz.us/bitcoin/patch.bitcoin-block-sz-limit

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
1511584703
Hero Member
*
Offline Offline

Posts: 1511584703

View Profile Personal Message (Offline)

Ignore
1511584703
Reply with quote  #2

1511584703
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511584703
Hero Member
*
Offline Offline

Posts: 1511584703

View Profile Personal Message (Offline)

Ignore
1511584703
Reply with quote  #2

1511584703
Report to moderator
1511584703
Hero Member
*
Offline Offline

Posts: 1511584703

View Profile Personal Message (Offline)

Ignore
1511584703
Reply with quote  #2

1511584703
Report to moderator
1511584703
Hero Member
*
Offline Offline

Posts: 1511584703

View Profile Personal Message (Offline)

Ignore
1511584703
Reply with quote  #2

1511584703
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2856


View Profile
October 03, 2010, 08:28:39 PM
 #2

Applying this patch will make you incompatible with other Bitcoin clients.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
October 03, 2010, 09:07:28 PM
 #3

Applying this patch will make you incompatible with other Bitcoin clients.
+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
October 03, 2010, 09:38:46 PM
 #4

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
October 04, 2010, 07:39:35 AM
 #5

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
October 04, 2010, 08:10:01 AM
 #6

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

It is also an incompatible change, as you see.....

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
martin
Full Member
***
Offline Offline

Activity: 150



View Profile WWW
October 04, 2010, 11:50:35 AM
 #7

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
October 04, 2010, 06:33:55 PM
 #8

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change Smiley

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
October 04, 2010, 07:48:40 PM
 #9

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being 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.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
October 06, 2010, 01:09:04 AM
 #10

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change Smiley

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.

appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
October 20, 2010, 07:50:02 PM
 #11

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change Smiley

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.

I agree, especially since generators are both the source of blocks and "votes" in the network.  Since a block restriction would allow generators to charge higher transaction fees, they might "vote" against an increase in the max size in the future.

It seems unlikely to be a real problem though.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
November 20, 2010, 01:19:29 PM
 #12

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 25, 2013, 03:54:02 PM
 #13

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being 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.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.


It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.

My question is this: What will happen first?
1) Bitcoin transaction volume increases by a factor of 4
2) Current Bitcoin clients become obsolete.

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
markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
February 25, 2013, 04:34:27 PM
 #14

Hmm Satoshi wrote that over two years ago and we still aren't actually close to needing it yet.

Still I guess it mostly depends on how many more years it is going to be before someone actually goes out there and signs up Walmart or President's Choice or A&P (are they still around?) or Sainsbury's or something and actually shows us a little of this vast flood of users they keep yelling is going to descend upon us any moment now.

So far it seems possible the volume of ranting about vast numbers of users coming at us is actually inversely proportional to the number of users the ranter actually has signed up lined up ready to bring aboard.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 25, 2013, 05:03:11 PM
 #15

http://blockchain.info/charts/n-transactions With a 10x increase in the number of transactions over the last year it is reasonable to say that we can reach the 1MB limit in well under a year. The point is that in order to roll out a hard fork one has to delay its implementation way into the future in order to avoid chaos in the network. It we reach the limit before anything is done it will be way too late and a massive loss in confidence will result.

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
BitcoinINV
Sr. Member
****
Offline Offline

Activity: 448



View Profile
February 25, 2013, 05:08:56 PM
 #16

off-topic and I am sorry but I could not help myself. Why did satoshi ever stop posting visiting us?

ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 25, 2013, 05:23:23 PM
 #17

off-topic and I am sorry but I could not help myself. Why did satoshi ever stop posting visiting us?

There are many theories of this. One of them is can Bitcoin continue to function without centralized control? By leaving us he in effect left Bitcoin leaderless and that is by design. This block size issue is likely to be the perfect test since the community has no choice but to implement a hard fork. If Bitcoin survives this it will come out way stronger, there is however also a significant chance that block size issue will turn Bitcoin into a failed experiment.  By the way I would not consider your post off topic at all.  

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
markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
February 25, 2013, 05:29:47 PM
 #18

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Technomage
Legendary
*
Offline Offline

Activity: 1848


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 25, 2013, 05:30:08 PM
 #19

http://blockchain.info/charts/n-transactions With a 10x increase in the number of transactions over the last year it is reasonable to say that we can reach the 1MB limit in well under a year. The point is that in order to roll out a hard fork one has to delay its implementation way into the future in order to avoid chaos in the network. It we reach the limit before anything is done it will be way too late and a massive loss in confidence will result.

Exactly. We're not having these discussions too early at all, on the contrary. We will probably need 1 year of lead time for such a massive change, and indeed it is possible that we will be pushing the limit within 1 year. So this is no joke.

Prasos operates Denarium, Coinmotion and Bittiraha.fi. We have an equity offering now live! Check our pitch and invest at Invesdor.
BitcoinINV
Sr. Member
****
Offline Offline

Activity: 448



View Profile
February 25, 2013, 05:36:24 PM
 #20

Here soon blockchain.info is going to roll soo fast you can not even see the transactions.

ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 25, 2013, 05:55:26 PM
 #21

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-


Satoshi Dice is currently paying 0.001 BTC in fees per transaction which translates into 0.03 USD per transaction. I would not call this "dust spam". What we have here is exponential growth pushing against a hard limit. This is a prescription for disaster. Arguing whether the disaster happens in four months or sixteen months is beside the point.

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
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
February 25, 2013, 06:07:04 PM
 #22


Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Technomage
Legendary
*
Offline Offline

Activity: 1848


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 25, 2013, 06:08:37 PM
 #23

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.

Prasos operates Denarium, Coinmotion and Bittiraha.fi. We have an equity offering now live! Check our pitch and invest at Invesdor.
markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
February 25, 2013, 06:27:54 PM
 #24

Okay how about making max block size a configuration file / commandline variable?

From then on, no hard fork of the code would be required to change it, only, potentially, a hard fork of the blockchain?

Shops can have signs on their doors warning customers about the actual setting that shop uses for max block size, and customers can choose higher size supporting shops if they feel confident risking their money in blockchain branches they think might end up with less hashing power behind them than forks adopting a more traditional / more conservative limit?

Customers would maybe prefer merchants whose limit is set so high only a few miners world wide can handle it thus that have lower hash power, plus their coins will still be safe back on the original size branch because no higher size block can ever move any original sized block chain's coins anywhere at all.

Merchants wanting to actually be able to receive real original coins on the real original chain will set their clients to not approve blocks larger than those of the original chain, the chain which established the damn things have any value at all in the first place.

Maybe we should make two forks right away, a double sized block and a half sized blocks chain, and see which chain's coins best retain or gain value?

The config file setting method of setting the max will at least get rid of all the "we have to fork the code" excuses / arguments, reducing it to each node's choice what value to put in its config file. Thus putting the power with the nodes, not with the developers. (Which might be a really really really crappy idea. "Eat shit! Half a million houseflies can't be wrong!")

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
nikkisnowe
Member
**
Offline Offline

Activity: 104


View Profile
February 25, 2013, 06:55:30 PM
 #25

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 
misterbigg
Hero Member
*****
Offline Offline

Activity: 924


GET IN - Smart Ticket Protocol - Live in market!


View Profile
February 25, 2013, 07:16:38 PM
 #26

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

They aren't ridiculous or indecipherable at all. In fact they are a very polite way of mocking many of the clueless opinions from non-technical folks.


               ████
             ███  ███
           ████     ███
         ███  ███    ███
       ████     ███    ███
     ███  ███     ███    ███
   ████     ███     ███   ██
 ███  ███     █████████████████
███     ███     ███           ██
 ███      ███     ██          ██
   ███      ██████████      ███
     ███      ██████      ███
       ███      ██      ███
         ███          ███
           ███      ███
             ███  ███
               ████

GUTS
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
smart-ticket protocol for events
live product with market traction!
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
  BTC ANN
  WEBSITE
  BLOG
   
  SANDBOX
  WHITEPAPER
  BOUNTY
   
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
February 25, 2013, 07:45:42 PM
 #27


Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

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

dacoinminster
Legendary
*
expert
Offline Offline

Activity: 1162


Rational Exuberance


View Profile WWW
February 25, 2013, 08:21:43 PM
 #28


Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

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.

Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
February 25, 2013, 08:48:01 PM
 #29

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).

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.

mp420
Hero Member
*****
Offline Offline

Activity: 501


View Profile
February 25, 2013, 09:17:15 PM
 #30

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.
markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
February 25, 2013, 10:24:06 PM
 #31

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.

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.

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.

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.)

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.

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!" Wink

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 25, 2013, 11:19:32 PM
 #32

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.

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.

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.

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.)

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.

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!" Wink

-MarkM-

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"?

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
Technomage
Legendary
*
Offline Offline

Activity: 1848


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 25, 2013, 11:28:50 PM
 #33

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.

Prasos operates Denarium, Coinmotion and Bittiraha.fi. We have an equity offering now live! Check our pitch and invest at Invesdor.
markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
February 25, 2013, 11:34:42 PM
 #34

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"?

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1848


[LOL2X]


View Profile WWW
February 25, 2013, 11:43:41 PM
 #35

It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.



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


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 26, 2013, 12:03:40 AM
 #36

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.

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.

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
Technomage
Legendary
*
Offline Offline

Activity: 1848


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 26, 2013, 12:05:19 AM
 #37

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.

Prasos operates Denarium, Coinmotion and Bittiraha.fi. We have an equity offering now live! Check our pitch and invest at Invesdor.
ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 26, 2013, 12:30:06 AM
 #38

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

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
johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
February 26, 2013, 12:53:59 AM
 #39

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

About half maybe

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

ArticMine
Legendary
*
Offline Offline

Activity: 2072


Monero Core Team


View Profile
February 26, 2013, 01:07:09 AM
 #40

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

About half maybe

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

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.

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
Technomage
Legendary
*
Offline Offline

Activity: 1848


Affordable 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.

Prasos operates Denarium, Coinmotion and Bittiraha.fi. We have an equity offering now live! Check our pitch and invest at Invesdor.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2856


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: 1162



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: 2450


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: 89


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: 2072


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: 1246


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
Legendary
*
Offline Offline

Activity: 1344


[[[],[]],[[],[]]]


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

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
_biO_
Full Member
***
Offline Offline

Activity: 167


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: 602



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: 742


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: 742


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: 602



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: 602



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: 742


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.
unamis76
Legendary
*
Offline Offline

Activity: 1386


View Profile
June 03, 2015, 07:26:57 PM
 #61

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.

So just because blocks will not jump overnight makes it not important to think about changing block size?
samson
Legendary
*
Offline Offline

Activity: 1246


View Profile
June 03, 2015, 07:32:18 PM
 #62

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.

So just because blocks will not jump overnight makes it not important to think about changing block size?

No, you misread my post.

slaveforanunnak1
Hero Member
*****
Offline Offline

Activity: 644



View Profile
June 19, 2015, 04:47:23 AM
 #63

I wonder if Satoshi ever talk about payment-channels ?

Looking Back with Adam, Wei Dai couldn't fathom

https://soundcloud.com/proofofbeats/whonakamoto
ammy009
Sr. Member
****
Offline Offline

Activity: 306


★Pi Coin★ [POS+POW] [NO ICO] !


View Profile WWW
June 19, 2015, 09:06:27 AM
 #64

this patch is included in XT bitcoin wallet ... I guess

coins101
Legendary
*
Offline Offline

Activity: 1400



View Profile
June 25, 2015, 10:11:05 AM
 #65

I've been sitting on the fence a bit trying to figure out what's what.

Having deployed a payment service intended for mass use inside one of the top 3 global retailers, you do need to plan ahead for optimistic outcomes and always keep the end users experience with your product in your sights.

I have come to the conclusion that while you don't need to update now, or possibly not for another year, the sooner you do it the less of an impact it will be for new adopters.

What is being discussed here is that we should wait until Bitcoin becomes more popular before making a hard fork. That's precisely the wrong time to do it.

Do it in anticipation of more transactions so that people coming to Bitcoin won't be reading news stories about a major upgrade that might cause problems.

We also have to consider that nearly $1bn in VC money is going in to development. That investment will soon see new services pouring out and those firms will all have promotional money. The last thing they would want is to start a promotional push, and then face the same situation of having to tell their users that a major update is needed and the update carries some risks.

I think that a hard fork should be made in line with BIP100. The hard fork should carry 1mb blocks as a starting point, but with some dynamic scaling options using just in time delivery to enable soft forking for increasing blocks sizes when capacity increases are required.

This should be part of a series of moves that seeks to take Bitcoin out of Beta.  Removing the limit means that the protocol can scale to Visa levels and beyond.

The introduction of Sidechains and Lightning networks means that capacity can be co-managed with micro-payment and off chain channels doing some of the heavy lifting. A dynamic model allows for these systems to work alongside Bitcoin block size planning.

Bitcoin is no longer a proof of concept project. The concept has been proven. Bitcoin Core 0.11 should be the last beta release cycle. Sidechains and Lightning type networks should be dovetailed to work with an eventual Bitcoin Core 1.0 production ready release.

edit

https://bitcoin.org/en/alert/2015-07-04-spv-mining

puck2
Full Member
***
Offline Offline

Activity: 233



View Profile
August 20, 2015, 06:41:42 PM
 #66

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

Prescient  Shocked
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!