I worry a lot that there is a widespread misunderstanding that blocks being "full" is bad-- block access is a priority queue based on feerate-- and at a feerate of ~0 there effectively infinite demand (for highly replicated perpetual storage). I believe that (absent radical new tech that we don't have yet) the system cannot survive as a usefully decentralized system if the response to "full" is to continually increase capacity (such as system would have almost no nodes, and also potentially have no way to pay for security). One of the biggest problems with hardfork proposals was that they directly fed this path-to-failure, and I worry that the segwit capacity increase may contribute to that too... e.g. that we'll temporarily not be "full" and then we'll be hit with piles of constructed "urgent! crash landing!" pressure to increase again to prevent "full" regardless of the costs. E.g. a constant cycle of short term panic about an artificial condition pushing the system away from long term survivability.
I worry too, but you appear to be adding to this misunderstanding. You are saying blocks can always be full (if the miners wished) because there are infinite 0 fee transactions in the memool. Therefore, any increase is useless to get blocks less than full. Therefore every increase will be filled with 0 fee transactions to infinity. Blocks have recently been full of fee paying transactions, not 0 fee transactions. Now adoption is on stop for a year. (I know core want it this way, escalating fees. dynamic fee market) 0 fees is not an issue here. 0 fees have nothing to do with full blocks or required blocks size. |
|
|
|
After reading the whitepaper, and Satoshi's other writings, I bought Bitcoin.
If you read and understand what he wrote, ...
You're misrepresenting Satoshi if you think cherry-picking things he's said to support a bigblocks perspective is the sum total of his reasoning on the matter: it isn't. Good post xDan, Very representative of satoshi's thinking on scaling, fees and time. It is not cherry picking to provide 5 quotes and also, as you said, "read and understand what he wrote". Carlton Banks provides no counter quote, as usual, just goes on to say "you had no reasonable expectations that Satoshi would ... always be right" I think your expectation was reasonable. Far more reasonable than Banks expectation satoshi was always wrong. I also signed up to the simpler and safer satoshi Bitcoin. Not this barely tested, change everything, we know better, my internet is shit when I'm on holiday friendly, Banks bitcoin. |
|
|
|
it means that it will only be since Wednesday that we will be able to compare bitcoinqueue.com data with bitcoinfees.21 and it will then be interesting if the gap has closed by then as it should be the cast. PS: our data now seems to be coherent with blockchain.info, which is temporarily used as feed source. The gap with bitcoinfees.21 does not seem to be closing. Every price bracket is different? (i.e. 21-30 sat, 2650 tx pending Bitcoinqueue.com but only about 200 tx pending on Bitcoinfees.21) Bitcoinqueue's total transactions do seem to tally with Blockchain.info Therefore, Blockchain.info mempool does not tally with Bitcoinfees.21 mempool either. I had suspected Blockchain.info did not count zero fee transactions, but as Bitcoinqueue (taking from Blockchain.info) does have "some" zero fee, that does not seem to be the case. Can you explain this difference? (do you consider Bitcoinqueue "accurate" for seeing "the mempool", will it be "more accurate" if you tap directly into the network?) Can fees be accurately calculated if "the mempool" is a nonspecific thing, different to each site? (Blockchain.info are not publicly predicting fees of course, but do show "total" unconfirmed. Seems quite meaningless without scope) Sorry if I'm struggling to express my issue simply and clearly.  |
|
|
|
After months of testing, coding, and work, Er, that fucks it for me. Just increase the blocksize for now please Jihan, segwit needs more, er, testing. |
|
|
|
They're increasing more than what the Antpool owner has demanded, so what his issue is, I'm not sure tbh.
You need to catch up chum. |
|
|
|
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.
...I'd rather not sacrifice decentralization for user adoption.
...Most are just complaining here and there.
...I don't think you realize how difficult it is to deploy a successful hard fork.
That satoshi. Silly boy. Staff here wins hands down.  |
|
|
|
This is innovative scaling, unlike a block size increase.
Innovative scaling, like the dao. The segwit disaster is lurking. It is not to late yet, adoption may never come. Bitcoin may yet be saved. |
|
|
|
|
Hey Matt, me again!
Cool, I am only motivated by actually wanting to see this work.
I don't want to jump in too soon, but I have another question.
Why are there only about 800 transactions under <10 sat on your chart, and about 3700 transactions in total.
On bitcoin.info there are about 4100 transactions in total,
and on bitcoinfees.21 there are about 3500 transactions >10 sat, and 43000 10 sat and under?
|
|
|
|
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. |
|
|
|
Yes. Thats what I said you saiid. You cleverer than all of them people.
Having more knowledge does not imply being more intelligent, but sure, I'll take that. You don't have that knowledge. Yes, I know you cant understand 1+1=2=twice as much=scaling=solution.
That does not even make sense. I know. It is like advanced mathematics. The one you said finally gets it.
He's not a "Bitcoin sage".
I don't see the point of these posts. You aren't making arguments of any kind. Read the post above yours. Yet you have to but in? I read the post already. |
|
|
|
High fees = High security, Low fees = low security, its that simple. It really isn't that simple. Every single complaint on a delayed transaction can be traced to the following:
2. Not paying the appropriate fee to be included Not true. The recent backlog included recommended fee payers being over bid by new fee payers paying new (higher) recommended fees. That group suffered at least a few hours delay after paying appropriate fees. |
|
|
|
Lauda,
Anyone asking about a block size increase doesn't know what they are talking about. Lauda is more cleverer than them.
No. Anyone spreading the false information that a block size limit increase improves scalability or is a solution of any sort does not know what they're talking about. Yes. Thats what I said you saiid. You cleverer than all of them people. Obviously 2 mb is no solution at all. (wait for segwit 4mb with the 1.8mb effect)
Yes and yes. Yes, I know you cant understand 1+1=2=twice as much=scaling=solution. Yet someone who cannot spell or nothing is a bitcoin coding sage?
Who's the "Bitcoin coding sage"? The one you said finally gets it. |
|
|
|
From the roadmap, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htmlblock size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. 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. So core can't lose. Patches at the ready. |
|
|
|
https://bitcointalk.org/index.php?topic=1517883.msg15278600#msg15278600
Bullshit by people who don't know what they're talking about (again). A block size limit increase is no solution at all. It does not improve scalability, it does not do anything
Close but no cigar, bud. Bitcoin is immutable. Its blocksize is 1MB, if you give in to a socialist mob... they will stop at nothing until they make your pre-ipo company worthless... serious shizz brah. Soft fork is love.
Hard fork is hate, becuase it uses fource.
Someone finally gets it. Lauda, Anyone asking about a block size increase doesn't know what they are talking about. Lauda is more cleverer than them. Obviously 2 mb is no solution at all. (wait for segwit 4mb with the 1.8mb effect) Yet someone who cannot spell or nothing is a bitcoin coding sage?
|
|
|
|
Thanks - I had fun making it. Ethereum sounds promising but right now The DAO fiasco is a grave example of what happens when half baked code which attracted close to 250 million USD (value at one point) in investments got released without proper testing and/or clear goals. I hope the thieves are punished. Hopefully Ethereum will survive and thrive.
Funny vid. (did you make the other, same clip, hitler vids, "newbie") Half baked code + 250 million, lol. Segwit and 12 billion? Now that would be funny. Any plans? |
|
|
|
The collection process (tx feed) was killed by the kernel over last night  I will be adding monitoring soon, stats have started rebuilding around 9am UTC this Sunday. The sampling method, used for intervals 8h and higher, has been changed for the detailed view, and will be used for the simple view soon. Stay tuned! I thought something was wrong. Keep working, you'll get there! Looking better again now, with a quick glance. (it was flat lining, not now) I'll clear off if i'm annoying you now? |
|
|
|
snipped Guys, a question... when 21 MN bitcoins get mined completely.... mining will stop...How will the network run...
My purpose to ask ...I think this will not take much longer, not more than 1 and half year.
once mining stops 124 years from now. Did you get that important point 2double0 hero member. Fail. |
|
|
|
It's getting very annoying,2 days ago i sent a payment of 0.14 btc and it took about 3 hours to be confirmed.
This must be change asap otherwise it will hurt btc
No. Bitcoin is working as intended. Don't blame Bitcoin if: 1) You're cheap. 2) You don't know how to use it properly. I have yet to find someone that I know (which are mostly experienced members) that had "problems with this". Besides, Segwit is getting ready to be merged. The "awaited" capacity 'boost' will come with it. Yes. Bitcoin is working as intended by Core. Don't blame Bitcoin if: 1) You can't work out the correct Core dynamic fee. (you will also need to see the future to be sure ) 2) You didn't know paying higher and higher fees is in the Core roadmap. ...vvv |
|
|
|
Click on 2 years to clearly see the growth of transactions, and the inevitability of full blocks. 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. Core don't want bigger blocks. They want this fee market situation. This is Cores idea. We only have a 5% margin to full capacity and the effects are already being felt. We can not achieve 100% full blocks. 95% is about it, maybe 97%, not sure but 100% is not realistically achievable. I'm expecting the situation to get worse. Unless the block size is increased.
It is not possible to get any better, in the near future, under current Core plans. Unless users are driven away from Bitcoin. ..the problem its either pay more or wait. there is no mechanism for pay 90% and guarantee confirm in an hour, pay 80% and guarantee in 2 hours. its just pay more or wait.
That is a problem, and just adds to the correct fee confusion. As you say, this is hit and hope. Even "currently recommended" fees, in a rising market, suffer this problem. (as just seen) Due to Cores dynamic fees, the only (almost) sure way to get in the next block is to out bid all other current fee payers. |
|
|
|
|
Show Posts
