Average block size was 0.951 MB

[calkob]

See what happened on the 15th of June:

https://blockchain.info/charts/avg-block-size?timespan=30days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

I don't want to scare anyone but if there are some people who think that a block size increase isn't URGENT, they're wrong. We only have a 5% margin to full capacity and the effects are already being felt.
I made 2 transactions on Thursday, both with a 0.0001 BTC fee. One was 226 bytes and it went smoothly, another was 930 bytes, it took more than 4 hours to confirm. I'm expecting the situation to get worse. Unless the block size is increased.

So your 2nd transaction was nearly 4 times larger, did you increase your fee for that transaction x4, no so what did you expect?

[~Bitcoin~]

Most people's default fee is 0.0005BTC/KB, that's why your second transaction took lots of time to get confirmed.

I also think same, if you like to get your transaction confirmed without waiting for hours the only way is to pay higher fees (recommended fee).

[socks435]

Its a large block size so the speed of transaction is always depends in block size.. if it will happen in the future after block halving its impossible to use bitcoin as payment in other company and stores.. its nearly 1 mb i never experience it yet..

[Kaller]

Its a large block size so the speed of transaction is always depends in block size.. if it will happen in the future after block halving its impossible to use bitcoin as payment in other company and stores.. its nearly 1 mb i never experience it yet..

For most people, if you you use high fee, but the mempool transaction size is very large, you still cannot get confirmation in time.

[Lauda]

So your 2nd transaction was nearly 4 times larger, did you increase your fee for that transaction x4, no so what did you expect?

Obviously he didn't. Let's all blame the network because people don't know that flat fees don't work (in a sense where a fee works for transaction A but does not work for transaction B).

Its a large block size so the speed of transaction is always depends in block size..

It doesn't. The transaction speed remains the same. You might be talking about confirmation time.

For most people, if you you use high fee, but the mempool transaction size is very large, you still cannot get confirmation in time.

Yes you can. It seems like you don't know how it actually works.

[franky1]

lauda has no clue either.. he is arguing a one sided argument. he is not understanding the big picture.
no one should trust zero-confirms. and so when people talk about transactions they are not just talking about relayed data.. but a settled payment.

that should be what everyone should be thinking.
making a payment should be the term for just relaying it and having it zero-confirmed. but a settled payment is a transaction.

EG
"the transaction is complete when adam pays X to jeff and jeff pays Y and both parties are happy."

you can even google it. "transaction complete" no where does it say that a transaction is complete where a person just waves a bank note in the air. its complete when the deal/contract is deemed forfilled and settled

its also why LN prefers to call the multisigs sat in mempool and relayed adhok as "payments" and payment channels, rather than transaction channels.
because a transaction in the real world is about when a payment is deemed settled

its why a bank statement has a list of transactions and a separate list of "pending"..

[Quickseller]

A spam transaction with a below average 0.0001 BTC fee confirmed after 4 hours. So what? I think this shows that a healthy fee market is not fully developed, because spam transactions like OP's still receive this kind of premium service.

(I haven't actually seen a txid for the OP's transaction, but okay). According to theymos, a "spam transaction" is one that create undesirable extra load on the network due to not following Bitcoin best practices(source). I don't think that creating a single transaction with slightly lower-then-"recommended" fees attached would be considered not following Bitcoin best practices, and thus should not be considered as spam.

From what I have been reading on reddit, some people are considering a spam transaction to be one that does not have a sufficient fee to be included in the first block (eg is not among the 1,000 kb of highest fee/kb as of when the first block is found after it is broadcast). This (greatly expanded) definition of "spam" however goes against the long standing practice of including a lower fee when a transaction does not need to be confirmed in the very next block.

The risk to the network, and to Bitcoin, is that either because of "spam transactions" or "genuine" transactions, that more then 1MB worth of transactions is created over long periods of time, which will create an ever growing backlog of transactions (even with RBF), and will cause the required fee to get a transaction confirmed to grow at an exponential rate.

Not raising the maximum block size also poses a risk to both the security of Bitcoin and Bitcoin itself, because there is a point at which people will decide to simply stop using/holding bitcoin when the cost to use Bitcoin becomes too high, and because there is a maximum transaction fee that users of Bitcoin will be willing to pay (in theory). This means that there is a cap to the total block reward, and that this cap will decrease over time (due to the decreasing block subsidy), which means that the cost to attack the network will decrease over time. If the maximum block size were to increase (to say 2 MB - now), then the (theoretical) maximum block reward would increase as well. I would also speculate that the total block reward would increase following a maximum block size increase due to more tx fee paying transactions being included in each block

[franky1]

(I haven't actually seen a txid for the OP's transaction, but okay). According to theymos, a "spam transaction" is one that create undesirable extra load on the network due to not following Bitcoin best practices(source). I don't think that creating a single transaction with slightly lower-then-"recommended" fees attached would be considered not following Bitcoin best practices, and thus should not be considered as spam.

true.

From what I have been reading on reddit, some people are considering a spam transaction to be one that does not have a sufficient fee to be included in the first block (eg is not among the 1,000 kb of highest fee/kb as of when the first block is found after it is broadcast). This (greatly expanded) definition of "spam" however goes against the long standing practice of including a lower fee when a transaction does not need to be confirmed in the very next block.

and the funny part is if simply not having priority to get into the next block should be deemed spam.. then lets laugh at the term "locktime" too..

The risk to the network, and to Bitcoin, is that either because of "spam transactions" or "genuine" transactions, that more then 1MB worth of transactions is created over long periods of time, which will create an ever growing backlog of transactions (even with RBF), and will cause the required fee to get a transaction confirmed to grow at an exponential rate.

and thats why a "pay more or wait forever" is not a free market thing(its open market, totally different and bad). and should not be something we are pushing for especially when pools dont need fees right now anyway.

we should be opening up scalability. we should have done it last year. as it seems we are not even gonna get it this year either. even if segwit code is released it wont be usable for months. so dont expect blockstream(core) to be the saving grace any time soon. by the time their 1.8x proposed capacity growth arrives it would be too late.

[Real-Duke]

Sent a payment of 1,5btc on tuesday that was confirmed today morning after ~5days!
Have forgotten to check the mempool before I sent the coins. With 35k open transactions and a small fee of 0,00002...not my best idea so far 

Damn that is a long time to confirm, you're obviously clued up though & you realise why, the fee was way too small
I always pay higher than the average fee because I'm always keen to see quick confirmations.

I check this site before sending coins: https://tradeblock.com/bitcoin/
Look at the 15th June where I didn't do my homework...in normal times (like now) my transactions are in a block within 45min latest even with my very small fee

[rizzlarolla]

A spam transaction with a below average 0.0001 BTC fee confirmed after 4 hours. So what? I think this shows that a healthy fee market is not fully developed, because spam transactions like OP's still receive this kind of premium service.

(I haven't actually seen a txid for the OP's transaction, but okay). According to theymos, a "spam transaction" is one that create undesirable extra load on the network due to not following Bitcoin best practices(source). I don't think that creating a single transaction with slightly lower-then-"recommended" fees attached would be considered not following Bitcoin best practices, and thus should not be considered as spam.

From what I have been reading on reddit, some people are considering a spam transaction to be one that does not have a sufficient fee to be included in the first block (eg is not among the 1,000 kb of highest fee/kb as of when the first block is found after it is broadcast). This (greatly expanded) definition of "spam" however goes against the long standing practice of including a lower fee when a transaction does not need to be confirmed in the very next block.

The risk to the network, and to Bitcoin, is that either because of "spam transactions" or "genuine" transactions, that more then 1MB worth of transactions is created over long periods of time, which will create an ever growing backlog of transactions (even with RBF), and will cause the required fee to get a transaction confirmed to grow at an exponential rate.

Not raising the maximum block size also poses a risk to both the security of Bitcoin and Bitcoin itself, because there is a point at which people will decide to simply stop using/holding bitcoin when the cost to use Bitcoin becomes too high, and because there is a maximum transaction fee that users of Bitcoin will be willing to pay (in theory). This means that there is a cap to the total block reward, and that this cap will decrease over time (due to the decreasing block subsidy), which means that the cost to attack the network will decrease over time. If the maximum block size were to increase (to say 2 MB - now), then the (theoretical) maximum block reward would increase as well. I would also speculate that the total block reward would increase following a maximum block size increase due to more tx fee paying transactions being included in each block

Core roadmap. Gmax.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
"In Bitcoin Core we should keep patches
ready to implement them as the need and the will arises, to keep the
basic software engineering from being the limiting factor."

Hedge your bets Core?
Block size "cannot" be raised, except with a patch when it all goes tits up?

Too late then Core. Trust will be lost.

[countryfree]

Hey, please!
This discussion shall not be about transaction fees. I just gave an example. The MAJOR issue we should be talking about is that blocks are 95% full. To deny this problem is like walking on the edge of a cliff and saying that everything's all right.

Could we please imagine what would happen if next week, there's 5% more transactions than there were on the 15th of June. What do we do when blocks are full?

[beastmodeBiscuitGravy]

Hey, please!
This discussion shall not be about transaction fees. I just gave an example. The MAJOR issue we should be talking about is that blocks are 95% full. To deny this problem is like walking on the edge of a cliff and saying that everything's all right.

Could we please imagine what would happen if next week, there's 5% more transactions than there were on the 15th of June. What do we do when blocks are full?

Uh, the lowest value transactions drop off. The agreed upon architecture is the main chain being a high value settlement network, akin to transferring gold. Lightning Network will be able to service general use payments.

[Quickseller]

The agreed upon architecture is the main chain being a high value settlement network, akin to transferring gold.

Who agreed to this? I don't believe this is how Bitcoin can be described currently, nor ever in the past, and I am not aware of any consensus for the status quo to be changed to this.

[beastmodeBiscuitGravy]

The agreed upon architecture is the main chain being a high value settlement network, akin to transferring gold.

Who agreed to this? I don't believe this is how Bitcoin can be described currently, nor ever in the past, and I am not aware of any consensus for the status quo to be changed to this.

This is built upon, an overlay to, the status quo. It's backwards compatible, no client upgrade is required.

[Quickseller]

The agreed upon architecture is the main chain being a high value settlement network, akin to transferring gold.

Who agreed to this? I don't believe this is how Bitcoin can be described currently, nor ever in the past, and I am not aware of any consensus for the status quo to be changed to this.

This is built upon, an overlay to, the status quo. It's backwards compatible, no client upgrade is required.

You failed to mention who agreed to this...

[beastmodeBiscuitGravy]

The agreed upon architecture is the main chain being a high value settlement network, akin to transferring gold.

Who agreed to this? I don't believe this is how Bitcoin can be described currently, nor ever in the past, and I am not aware of any consensus for the status quo to be changed to this.

This is built upon, an overlay to, the status quo. It's backwards compatible, no client upgrade is required.

You failed to mention who agreed to this...

Well, the only needed components left are soft forks (backwards compatible and with BIP9, 29 concurrent soft fork proposals are possible). All it really takes is a handful of pool ops + status quo = we're good to go.

User/node agreement/permission is not required, nor even really relevant, by design.

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

[Holliday]

ha ha ha,, told you lauda would chime in

and WTF he is pretending there is no mempool now..

wait i got to quote him saying that for posterity sake

There is no such thing as "the mempool"

seriously he really needs to learn some bitcoin basics

oh this gave me a chuckle

certainly not with "35k open transactions". This solely depends on the settings that a specific node uses. My node has had 40-50k unconfirmed transactions on average for months, but you could clearly see that the mempool at other places (e.g. blockchain.info) was almost empty at times.

lauda's logic is based on the fact that bitcoin blocks dont need transactions to make a block,
but his false logic is that he will continue to say bitcoin is running fine even if there are no transactions, a couple transactions or thousands.. because he doesnt see, or want to see bitcoin as something useful for people actually transacting..

What are you on about? When Lauda said there is no "the mempool", he simply means that it's possible (actually more than likely) for nodes to have different mempools because they have different fee rules. For example, my mempool is typically less than 1MB and contains less than 1000 transactions. My node doesn't forward spam, so it rarely grows much larger than that (even during these spam attacks).

Simply increasing the block size will only lead to larger blocks full of spam. If that isn't obvious to you, well I don't know what to say.

Bitcoin's unique use case is censorship-proof transactions. This is why it's valuable. No one in their right mind should be concerned whether or not they can pay for a coffee using the-ledger-that-every-full-node-must-keep-a-permanent-record-of-forever and get cheap, fast confirmations to boot!

The problem is, most Bitcoiners are spoiled from the first 7 years of Bitcoin when block subsidies provided secure transactions for everyone. They need to realize that if we are going to have secure transactions in the future, we need to move away from the subsidized method of securing transactions to actually paying for them directly. Unfortunately, it looks like some spoiled brats are going to have to be dragged along kicking and screaming.

[Cryptonitex]

I agree, anyone that says that block size isn't going to be a problem, their stupid.

Bitcoin cannot withhold an economy on a large scale the way it is. And paying larger fees isn't the answer, that's just adding to the problem, disincentivising the use of Bitcoin.

Right now, the use of BitCoin I imagine isn't as big as it could be, when millions (hopefully billions) of people start to use Bitcoin, shit will get crazy.

[Lauda]

What are you on about? When Lauda said there is no "the mempool", he simply means that it's possible (actually more than likely) for nodes to have different mempools because they have different fee rules. For example, my mempool is typically less than 1MB and contains less than 1000 transactions. My node doesn't forward spam, so it rarely grows much larger than that (even during these spam attacks).

He's a troll, just ignore him. What I said was, there is no "the mempool" which would define that there are X unconfirmed transactions everywhere. This number differs heavily depending on the settings, and you've just made an example. My node relays everything as I want to keep track of the changes throughout the year.

Simply increasing the block size will only lead to larger blocks full of spam. If that isn't obvious to you, well I don't know what to say.

He's about to tell you that Blockstream this, or blockstream that or you're also part of Blockstream.

Bitcoin's unique use case is censorship-proof transactions. This is why it's valuable. No one in their right mind should be concerned whether or not they can pay for a coffee using the-ledger-that-every-full-node-must-keep-a-permanent-record-of-forever and get cheap, fast confirmations to boot!

Exactly. The intrinsic value of the blockchain lies within decentralization, immutability and censorship resistance.

I agree, anyone that says that block size isn't going to be a problem, their stupid.

Read the actual thread for once and ignore the trolls. The post above you gives decent input.

[Foxpup]

The problem is, most Bitcoiners are spoiled from the first 7 years of Bitcoin when block subsidies provided secure transactions for everyone.

Except they didn't. Even back then, cheapskates were complaining that free transactions took too long to be confirmed, and I've been trying to correct their attitude pretty much ever since I got into Bitcoin nearly 5 years ago. Since then, we've had new anti-spam measures, dynamic fee calculation, RBF, CPFP, and now SegWit* and LN to deal with problematic fees, but it's all useless: these are technical solutions to a social problem, and the problem is that people are too cheap to pay 50 cents to use an international payment system, and too impatient to wait more than 10 minutes for their funds to clear.

*Yes, I know SegWit is much more than a capacity increase, but the idiots I'm talking about don't know that. They only know that their barista won't serve them their coffee until they have 6 confirmations.