why transactions are taking too long ?

[VeritasSapere]

I hope you realize what it means in terms of governance to run Core. I am strongly opposed to their conception of Bitcoin governance regardless of the blocksize issue.

I too am terribly uneasy about such a small number of people holding the keys; they are vulnerable to coercion and/or simple misguidance.  I would be ok with the Classic guys taking the keys but they are vulnerable to the same things.  I don't have an answer.  Polarizing on the blocksize is not healthy.  Depolarizing is going to be the way forward for sure.  Would someone please point me at a site that reveals the current and historic legit traffic?

There is a solution, giving any one group the keys is problematic, the key to solving this problem is distributing this power just like Bitcoin has done for many other things. Multiple competing implementations distributes this power and avoids any singular developer team gaining to much power. This is how the governance of Bitcoin should work.

Like I said before, Bitcoin is a permisionless network. I consider all traffic legitimate unless the persons are malicious in their motivations, which can not always be proven or discovered.

[1714772505]

1714772505

[1714772505]

1714772505

[1714772505]

1714772505

[1714772505]

1714772505

[1714772505]

1714772505

[VeritasSapere]

I think you are mistaken, the problem is that there is not enough network capacity. Increasing the networks capacity solves the problem of congestion now. You need to think about this more long term, now is not the time to restrict the throughput of the network. If we have twice the network throughput it will be twice as expensive with the same fees to attack the network. This property increases as we increase the blocksize. Bitcoin will not be able to compete with the alternative cryptocurrencies when they can just increase the blocksize, this was always the intention with the original design of Bitcoin as well. In the long term we might have more expensive fees but I think that should be up to the free market to decide, not enforced through an economic policy tool like the blocksize limit. With an increased blocksize over the long term it will be much more expensive to attack the network in this way. Making Bitcoin more unreliable and expensive will simply just lead to its obsoletion, we can already see how Ethereum is rising in response to this crisis. Most altcoins already have a TPS in the hundreds, the 3-7 TPS of Bitcoin is just a bad joke there is no chance that Bitcoin will remain the dominant cryptocurrency if that remains the case.

Unfortunately even a 32MB blocksize (or even larger) can't be the answer.  Spammers could just load 'em up with crap low/zero fee transactions.

How much legit traffic is there right now?

In that case miners could put the spam into blocks making them pay for it, zero fee transactions will just get dropped. While also avoiding any confirmation dellays in the proccess. In the example that you mention, with a standard low transaction fee of 0.0001. It would cost approximately 6.4 Bitcoins per block to attack the network. At the current Bitcoin price it would cost approximately four hundred thousand dollars per day to attack the Bitcoin network with a thirty megabyte blocksize limit. I would argue that this is a much better defense against a spam attack compared to restricting the blocksize, while very importantly not sacrificing the utility of Bitcoin.

Bitcoin is a permisionless network, I do not think there even is such a thing as spam unless you can prove the malicious intentions of the spammers, which is sometimes the case. I do think that what we are seeing now is the network simply reaching capacity, which is why its capacity must be increased or Bitcoin risks being out competed and obsolesced by alternative cryptocurrencies and fiat.

Miners have a stake in the health of Bitcoin; it makes no sense for them to undermine it.

I agree, they would be doing this for the good of the network.

Hmm, I too thought about how large blocks let the spammers go broke faster *but* the larger blocksize also encourages lower fees.  Has anyone done the math (or simulation) to see how the two forces play out?

Low fees at this stage of Bitcoins development is a good thing and should be the desired state for maximizing adoption, adoption also being key to increased security and decentralization, a virtues cycle if you will. Bitcoin was always meant to be a high volume low cost network. Not a low volume high cost network, which is what Core is attempting to turn Bitcoin into, diverging from Satoshi's original vision.

[David Rabahy]

I see both sides.  Compromise.  Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward?  Get SegWit out the door as soon as it is really ready.

If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc.  Despite that I would do what I could to facilitate legit users paying reasonable fees.  The free lunch of zero-cost transactions is over.

So, maybe I wasted my time deinstalling Classic and installing Core.  *sigh*  Do I really have to break open the code and make my own version?

[David Rabahy]

Everyone please inform your self.

http://konradsgraf.com/blog1/tag/block-size-debate
https://medium.com/@riprowan/the-entire-debate-transcends-block-sizes-and-gets-to-the-fundamental-principles-of-bitcoin-as-c7f7bc1a493#.e6tlubrv7
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011973.html
https://medium.com/@jgarzik/bitcoin-is-being-hot-wired-for-settlement-a5beb1df223a#.7ek47hakx

I read through all of it; thank you.

What I see is a need to make burdensome things cost more.  Things like transactions that deliberately make pruning less effective.

[VeritasSapere]

I see both sides.  Compromise.  Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward?  Get SegWit out the door as soon as it is really ready.

If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc.  Despite that I would do what I could to facilitate legit users paying reasonable fees.  The free lunch of zero-cost transactions is over.

So, maybe I wasted my time deinstalling Classic and installing Core.  *sigh*  Do I really have to break open the code and make my own version?

I would encourage anyone creating their own versions.

Good to keep in mind that two megabytes is already a compromise. The first proposal was twenty megabytes, second proposal was eight megabytes. Classic represents the third proposal at two megabytes. If anything I think it is time for the other side to compromise. So far they have not moved an inch. I would even welcome a hard fork to 1.1 megabytes just to prove a point, that it can be done and to decrease all of the unnecessary fear mongering that surrounds such a change, at least then we would have a precedent.

[David Rabahy]

There are two ways to "pay"; 1) fees to miners, 2) send Bitcoins to an inaccessible address.  Paying miners is great and well worth it.  Sending Bitcoins to an inaccessible address "pays" all holders.  Perhaps we can make truly burdensome transactions costly by requiring they pay the latter.  Yeah, yeah, which transactions are so burdensome?

[VeritasSapere]

There are two ways to "pay"; 1) fees to miners, 2) send Bitcoins to an inaccessible address.  Paying miners is great and well worth it.  Sending Bitcoins to an inaccessible address "pays" all holders.  Perhaps we can make truly burdensome transactions costly by requiring they pay the latter.  Yeah, yeah, which transactions are so burdensome?

Fees are important over the long term, the block subsidy is meant to bootstrap adoption, however at some point fees are meant to replace the block reward entirely. I do not expect this to happen for several decades at least, though it is important to keep this in mind for the long term vision of Bitcoin.

Miners provide security to the network, so the fee is actually paying for a service, if the fee was burned that would not be the case. It is also good to keep in mind that any changes to Bitcoin need to be very conservative in order for them to have any chance to be implemented, just look at the blocksize limit, which was always meant to be increased and was just a temporary anti spam limit when first implemented. If it was easier to make changes to Bitcoin I would suggest incentivized full nodes and a self funding blockchain, fortunately there are some good sides to this conservatism as well.

[Yakamoto]

There are two ways to "pay"; 1) fees to miners, 2) send Bitcoins to an inaccessible address.  Paying miners is great and well worth it.  Sending Bitcoins to an inaccessible address "pays" all holders...

Personally I don't agree with that point, yet anyways, as anything that we get rid of doesn't have a noticeable impact on the value of Bitcoin.

Once Bitcoin becomes increasingly scarce, then Bitcoin that has been made inaccessible will finally show some value, but until then, Bitcoin being generated currently outweighs a majority of the Bitcoin being discarded.

[Zeke2345]

Agree with the problem of which are burdensome,it would be hard to sort or cap with out being restrictive in nature.
Will read the links now and catch up on this aspect before I spout off.

[David Rabahy]

I see both sides.  Compromise.  Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward?  Get SegWit out the door as soon as it is really ready.

If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc.  Despite that I would do what I could to facilitate legit users paying reasonable fees.  The free lunch of zero-cost transactions is over.

So, maybe I wasted my time deinstalling Classic and installing Core.  *sigh*  Do I really have to break open the code and make my own version?

I would encourage anyone creating their own versions.

Good to keep in mind that two megabytes is already a compromise. The first proposal was twenty megabytes, second proposal was eight megabytes. Classic represents the third proposal at two megabytes. If anything I think it is time for the other side to compromise. So far they have not moved an inch. I would even welcome a hard fork to 1.1 megabytes just to prove a point, that it can be done and to decrease all of the unnecessary fear mongering that surrounds such a change, at least then we would have a precedent.

Ok, fine.  What do I do?  Offer to pay a bounty for my version?  How much is this going to cost me?  Literally dust off my coding skills?  Geesh, I did download the Git software a while ago and goofed around with it.  I am an old VMS cli kind of guy so this is out of my comfort zone.

[VeritasSapere]

I see both sides.  Compromise.  Increase the blocksize to 1.1MB just to see how it goes; nothing like a little practice; who ever said doubling it was the only way forward?  Get SegWit out the door as soon as it is really ready.

If I were king (you could make a worse choice) then I would set the blocksize to 32MB (or whatever maximum value is workable right now) and then get to work on overcoming that maximum via block segmentation, etc.  Despite that I would do what I could to facilitate legit users paying reasonable fees.  The free lunch of zero-cost transactions is over.

So, maybe I wasted my time deinstalling Classic and installing Core.  *sigh*  Do I really have to break open the code and make my own version?

I would encourage anyone creating their own versions.

Good to keep in mind that two megabytes is already a compromise. The first proposal was twenty megabytes, second proposal was eight megabytes. Classic represents the third proposal at two megabytes. If anything I think it is time for the other side to compromise. So far they have not moved an inch. I would even welcome a hard fork to 1.1 megabytes just to prove a point, that it can be done and to decrease all of the unnecessary fear mongering that surrounds such a change, at least then we would have a precedent.

Ok, fine.  What do I do?  Offer to pay a bounty for my version?  How much is this going to cost me?  Literally dust off my coding skills?  Geesh, I did download the Git software a while ago and goofed around with it.  I am an old VMS cli kind of guy so this is out of my comfort zone.

Its cool, I was just playing around, it is the principle that is important. Anyone should be able to create their own implementation and run it on the network. We do have a few choices now fortunately. I like Bitcoin Unlimited myself which is also compatible with any of the changes in Bitcoin Classic, which has the best chance of reaching "consensus". There are now five major implementations of Bitcoin, Core, Classic, Unlimited, BTCD and LibBitcoin. There are more obscure ones out there as well that individuals have created according to their own tastes. Bitpay has an implementation of Bitcoin with an adaptive blocksize which is what Classic will be moving towards in the future as well.

[David Rabahy]

Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already.  Would 1.1MB really kill ya?  You are getting a bad reputation out here.  If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything.  You don't think you can ride 1MB forever, right?  Give us a clue; when do you think a blocksize increase will be appropriate?

[mexxer-2]

Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already.  Would 1.1MB really kill ya?  You are getting a bad reputation out here.  If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything.  You don't think you can ride 1MB forever, right?  Give us a clue; when do you think a blocksize increase will be appropriate?

Sorry to break it to ya but the core devs would hardly be having a look at this site, let alone in one of the specific thread where one random individual has made a suggestion. Github, the place for Bitcoin geeks is the only place 

[Lauda]

Bitcoin is a permisionless network, I do not think there even is such a thing as spam unless you can prove the malicious intentions of the spammers, which is sometimes the case.

With a little bit of blockchain analysis you can do this; this is what happened yesterday. I'd also put dust into this category.

Ok, fine.  What do I do?  Offer to pay a bounty for my version?  How much is this going to cost me?  Literally dust off my coding skills?  Geesh, I did download the Git software a while ago and goofed around with it.  I am an old VMS cli kind of guy so this is out of my comfort zone.

Step 1) Ignore the manipulation attempts. An increased block size limit does not solve this problem.
Step 2) Wait for Segwit and LN.

The easiest/best/only? way to fight spam is by making it expensive for them.  So far the only answer appears to be increasing fees.  Attempting to increase adoption with unrealistic low/zero fees is misleading.

Even if we had a 2MB block size limit/Segwit this could still happen any day (as it was an attack). This doesn't solve the problem. Something that could be considered a 'solution' with instant transactions is the Lightning Network (you might want to read up on it).

One day we will need to increase the block size in order to accommodate non-spam traffic; we just aren't there yet.  How much non-spam traffic is flowing through these days?

According to the roundtable (a 'unnamed' expert said) that blocks are 40% full right now (IIRC) and that the rest was spam.

[David Rabahy]

Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already.  Would 1.1MB really kill ya?  You are getting a bad reputation out here.  If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything.  You don't think you can ride 1MB forever, right?  Give us a clue; when do you think a blocksize increase will be appropriate?

Sorry to break it to ya but the core devs would hardly be having a look at this site, let alone in one of the specific thread where one random individual has made a suggestion. Github, the place for Bitcoin geeks is the only place 

Oh; thanks.  Um, shoot; how does one post to Github effectively?

[VeritasSapere]

Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already.  Would 1.1MB really kill ya?  You are getting a bad reputation out here.  If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything.  You don't think you can ride 1MB forever, right?  Give us a clue; when do you think a blocksize increase will be appropriate?

Sorry to break it to ya but the core devs would hardly be having a look at this site, let alone in one of the specific thread where one random individual has made a suggestion. Github, the place for Bitcoin geeks is the only place  

Oh; thanks.  Um, shoot; how does one post to Github effectively?

If you did post such a concept on any one of the main Core channels they would just ban and censor you, I would be very surprised if that did not happen. This is part of why many prominent developers have moved to alternative implementations where these issues can be discussed and implemented.

[David Rabahy]

Bitcoin is a permisionless network, I do not think there even is such a thing as spam unless you can prove the malicious intentions of the spammers, which is sometimes the case.

With a little bit of blockchain analysis you can do this; this is what happened yesterday. I'd also put dust into this category.

Ok, fine.  What do I do?  Offer to pay a bounty for my version?  How much is this going to cost me?  Literally dust off my coding skills?  Geesh, I did download the Git software a while ago and goofed around with it.  I am an old VMS cli kind of guy so this is out of my comfort zone.

Step 1) Ignore the manipulation attempts. An increased block size limit does not solve this problem.
Step 2) Wait for Segwit and LN.

The easiest/best/only? way to fight spam is by making it expensive for them.  So far the only answer appears to be increasing fees.  Attempting to increase adoption with unrealistic low/zero fees is misleading.

Even if we had a 2MB block size limit/Segwit this could still happen any day (as it was an attack). This doesn't solve the problem. Something that could be considered a 'solution' with instant transactions is the Lightning Network (you might want to read up on it).

One day we will need to increase the block size in order to accommodate non-spam traffic; we just aren't there yet.  How much non-spam traffic is flowing through these days?

According to the roundtable (a 'unnamed' expert said) that blocks are 40% full right now (IIRC) and that the rest was spam.

Hey, VeritaSapere; please stop manipulating me.

Perhaps a larger block size doesn't solve "this" but it certainly wouldn't hurt, right?

My son and I run an informal side chain in our brains; not terribly precise but it gets the job done.  We keep track of how much we owe each other (I paid for the ski lift ticket; he bought lunch, etc.) and when it gets big enough we settle in Bitcoin (or sometimes in US dollars; whichever is handy).  I think LN is like this but fancier and clearly way more precise/reliable.  If my son tries to screw me he's out of the will.

[David Rabahy]

Hey, Core development guys; listen up; C.O.M.P.R.O.M.I.S.E. already.  Would 1.1MB really kill ya?  You are getting a bad reputation out here.  If 1.1MB is a waste of time in your eyes then, ok, 2MB; whatever, it is more about appearances than anything.  You don't think you can ride 1MB forever, right?  Give us a clue; when do you think a blocksize increase will be appropriate?

Sorry to break it to ya but the core devs would hardly be having a look at this site, let alone in one of the specific thread where one random individual has made a suggestion. Github, the place for Bitcoin geeks is the only place  

Oh; thanks.  Um, shoot; how does one post to Github effectively?

If you did post such a concept on any one of the main Core channels they would just ban and censor you, I would be very surprised if that did not happen. This is part of why many prominent developers have moved to alternative implementations where these issues can be discussed and implemented.

Fine; I will deinstall Core and install, um, which one?  BU?  That will teach those darn Core guys; ignoring/banning me wasn't very nice.  If they aren't nice to enough people then they will lose control.

[VeritasSapere]

I am not manipulating you, if anyone is it is the person telling you that I am. Manipulation has a very specific meaning. I mean what I say, and I am not appealing to irrationality and emotion. If you do not believe me regarding the censorship you are welcome to test that out for yourself. I just want to see Bitcoin thrive and I earnestly believe that increasing the blocksize is the best way to do this.

The eventual solution will be to not care how big it gets.

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.

The threshold can easily be changed in the future.  We can decide to increase it when the time comes.  It's a good idea to keep it lower as a circuit breaker and increase it as needed.  If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.

Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

I’m sure that in 20 years there will either be very large transaction volume or no volume.

[Lauda]

Perhaps a larger block size doesn't solve "this" but it certainly wouldn't hurt, right?

If by "wouldn't hurt" you mean it would waste unnecessary resources and add more cost to node operators, then yes. This does not however mean that the block size limit will never be increased. The issue is much more complex.

I just want to see Bitcoin thrive and I earnestly believe that increasing the blocksize is the best way to do this.

Regardless of how many times you repeat the lie, it won't make it true. What you hope for is not possible in that way.

If you did post such a concept on any one of the main Core channels they would just ban and censor you, I would be very surprised if that did not happen.

This does not happen.

This is part of why many prominent developers have moved to alternative implementations where these issues can be discussed and implemented.

If by "prominent" you mean random developers who haven't contributed much to Bitcoin (if at all), then yes.