i think its time lauda goes spend a few hours to ask his friends the difference between xthin and headers first
Again, I have no "friends" to ask. Anyhow, both of those proposals are such garbage that looking into them is a waste of time. ill give hm a hint.
If anything, history has taught us that the information provided by you is false in most cases. Please let me know once miners measure 95% node adoption.  |
|
|
|
We never wanted a split, we just want bitcoin to be available to everyone.
If you really think idea behind these controversial fork attempts is that, then I'm sorry to tell you, but you've been deceived. You may want that, which is perfectly fine, but that's not the intent of the people who started with the controversial forks. The facts still state that you are wrong, and 4MB blocksizes are perfectly safe. 20MB with xthin is also perfectly safe. But i'm happy with 4MB for now, or even 2MB until we need more.
Saying "xx MB block size is safe" is wrong. Saying "xx MB block size is safe if we limit the TX size to xx or less" may be true. These two statements are inherently different, ergo I'm not wrong. No one has the money to set up a several months long non-stop spam attack.
This got to be a bad joke, right? A fair amount of people have enough money to spam up the network for a very long time. This is all legitimate users and you know it.
Please post the testing methodology that extracts 'real user transactions' from the pool of all transactions, i.e. excludes 'spam transactions'. I'm sure everybody would like to know how this revolutionary method works. Quadratric validation time doesn't matter if you just limit the transaction size to 1MB or lower.
The statement contradicts itself. It matters until you add even more limits to Bitcoin. |
|
|
|
No it's not. We can safely increase the limit to at least 4MB right now, and there won't be a problem.
Yes it is and no we can not. It has been tested on testnet already. Stop spreading misinformation. There's nothing dangerous about bigger blocks.
The BU testing methodology is garbage and should not be used as 'evidence' for anything. The reason of the blocksize limit was not decentralization, not safety, but anti-spam.
Both safety and anti-spam. The blocks aren't full of spam
You can't prove this and you know it. Also it's ridiculous to say 2MB blocksize is dangerous while saying we should get 2MB later. f it's not dangerous later it's not dangerous now either.
No, it is not. You clearly have no idea what you're talking about. Quadratic validation time without Segwit. I highly doubt you even understand the big O notation. |
|
|
|
|
This topic has been moved to Trashcan.
Reason: Insubstantial duplicate. Use the search function and/or look around the section.
|
|
|
|
optional change of POW (modified scrypt, CPU mineable and hopefully ASIC-resistant)
This obviously wouldn't be Bitcoin anymore, and no way is any miner ever going to support this. Not to mention the amount of botnets that will hop onto this bandwagon. an implementation of BitPay's adaptive block size algorithm, adjusting in the range 2MB-4MB
Unsafe without Segwit, although I like the idea of adaptive block size algorithm with an lower and upper bound (as long as the upper one isn't beyond safe limits).
I have no idea why they want this to be associated with Bitcoin when it clearly isn't Bitcoin. I'll take a wild guess: Manipulation. |
|
|
|
Exactly, it's just a spin-off of the actual bitcoin blockchain  . I don't care about the name bitcoin classic, unlimited or I don't know... So introducing confusion in addition to the media portraying Bitcoin as a joke due to that is what you want? the important thing is that they increase the blocksize and add other few interesting things.
Fun fact: Neither one of those teams have developed anything worth incorporating into Bitcoin Core. Don't get me started on idiotic ideas such as "header-first mining". |
|
|
|
says the guy who hasnt even read a line of code.
nor even knows a line of core code without spoonfeeding
I don't need to read nor know a single line of code in BU. There's something called third party code review (which unfortunately isn't as common as it should be). Oh wait, you wouldn't know that since you don't resort to knowledge nor rational arguments, but rather character assassination. |
|
|
|
-snip-
I suppose we can keep musing about how irrational it would be for such blocks to mined... but, food for thought.
But, but, BU team promised me everyone would be playing nice and creating sigop friendly blocks? -snip-
months ago lauda attempted to debunk WATCHING videos as that was only download bandwidth to which i replied months ago with UPLOAD stats of livestream recording at that time. and today was reminding him of the facts that the internet as a whole is not a problem for 2-4mb blocks upload and by default definitely no issues for download
Comparing live-streaming to running a node is also a 'false analogy fallacy'. One has incentives, the other one doesn't for example. im not going to get into the debate of someone else advocating 20mb, as that is just poking laudas bear and not something the community as a whole could consider right now(though technically possible).
Sure, even 1 TB blocks are technically possibly. This doesn't make it safe. which is why i laugh hard when lauda was saying 2mb was bad.. yet his friends are saying 4mb is acceptable, and lauda has now backtracked to say 4mb is acceptable "because its core". but 2mb is still bad.
I have no friends, ergo this statement is an outright lie. lauda will still not be happy and will always try to debate some crap to keep core as the overlords,
As said many times, not that it matters, I have no relationship to any Core contributor whatsoever. rather than all implementations coming to a joint agreement making all implementations all on the same level playing field coming to a joint consensus, which the community thought we reached before last christmas.
The problem is that these "other implementations" only have half-baked, horribly coded improvements. |
|
|
|
Probably not something for me then (see my previous post) if it's around 300-400 GB of upload bandwidth per month.
It really comes down how you set-up your own node. You could implement a higher min-relay policy, in addition to limiting your own speed & number of connections to lower thresholds. There are also alternatives, such as running in blocks only mode or setting up upload targets. I do have an unlimited plan, but I'm pretty sure it has a 'fair use' clause in the contract.
You can't really know until you try! 83GB is no joke for most users. The blockchain is also getting larger and larger every year so running a node will get only harder.
People are forgetting things like: 1) Initial sync cost and time. 2) Lack of incentive of running a node (unless you feel strongly about decentralization). 3) Time request to fix problems once something goes corrupt (e.g. having to run a reindex). |
|
|
|
Technically as an escrow, I'm not to be swayed by threats or commands, only to follow the logical path.
That is correct. In the case of any disputes, you're the one who should make the resolving decision. Just because one side may disagree with it, that does not make it wrong. |
|
|
|
|
Let me get this straight: You own three accounts, and got banned for copy/paste spam. You want the staff to un-ban you, and the primary reasoning for this is your own ignorance? That's not how this works.
Something in the lines of "ignorance of the law excuses not" should also apply to the rules, as in you can not escape liability for breaking the forum rules just because you were not aware of them.
|
|
|
|
|
I don't see why this should even be a question. It is common sense that over time, running a Bitcoin node is going to be costlier with resource usage (disregarding the changes in price for bandwidth and per GB of storage). I'd suggest running a node your home if you have unlimited bandwidth. You could limit it to something low like 2 - 4 Mbps upload speed (depending on your plan) with software (e.g. wondershaper for Linux).
My node has about 40-60 connections, is capped at 2 Mbps and spends around 300-400 GB of upload bandwidth per month.
|
|
|
|
If you are not against blocksize increase, then why do you keep arguing against it?
Because it's the wrong position to have and it has many cons which should not be ignored. 2 MB is inherently dangerous, hence the additional limitations as added by Gavin's BIP for Classic. Segwit aims to solve this, in addition to increasing the capacity with usage (which should result in around 170-180% increase). After Segwit, we should look into acceptable block size increases. In addition to all of this, deploying a HF just for the sake of a block size increase is horribly inefficient. There are certainly some changes/optimizations that require a HF and those should be deployed along side the block size increase. I'm not taking things out of context, although I do remember someone doing just that a few posts ago.
Yes, you have. It's still better than the franky1's "You all want Monero to succeed" fantasy. |
|
|
|
Here you are disagreeing with limiting the transaction size. (limiting it to 1MB is implied, just to be sure you understand, the current limit is 1MB because the blocksize is 1MB and therefore a transaction larger than 1MB doesn't fit).
What was meant is that I'm against additional imposed limitations in order to favor a HF. I'm undecided about TX size as there haven't been that many discussions about it. -snip-
and here you are disagreeing with increasing the block size.
Listing cons of something != disagreeing with it. There is likely going to be some headroom with Segwit, where an additional increase of 1-2 MB may be okay. I'm still waiting for Luke-Jr's proposal. So even though those statements weren't direct quotes (I never implied they were quotes), I can proof that they align with your statements. Therefore you are contradicting yourself, and falsely accusing me of lying.
Taking things out of context in other to strengthen your position is what one would usually define a lying manipulator as. And yet, that's exactly what bitcoin is doing right now.
No, that's not what Bitcoin "is doing right now". Bitcoin can't do anything on its own as Bitcoin isn't an entity that can decide for itself. In addition to that, the analogy is false since the limit in currently a safeguard from the DOS risk at 2 MB or higher. Not enough time for what? Verifying with an abacus?
I'll even risk by saying that enthusiast grade hardware will not be able to validate a sigop expensive 20 MB block in time. Someone would need to test this out to confirm though. |
|
|
|
Statement 1:
I don't want blocks larger than 1MB
Statement 2:
I might want transactions larger than 1MB
These are not compatible with each other (not to mention, they're ridiculous, even in their own, but together they're even worse).
I have made neither one of these statements. Now you're just an outright liar and manipulator (say hi to Veritas for me). -snip-
Ad hominem nonsense due to losing ground. You're only showing that talking with you is a massive waste of anyone's time.
You're the one wasting time with wrongful information trying to mislead people into supporting something that is both inherently controversial and dangerous. Still, in practice even a cheap 500GB drive would last for at least half a year, and most likely longer because it's unlikely blocks of 20MB would be filled every time at least for the next few years.
Until somebody "turns on" the spam again, and suddenly everyone is stuck with massive bloat. And xthin blocks would solve that issue too, but Core doesn't support xthin (of course, because core doesn't support improvement).
Xthin is half-baked level improvement, just like pretty much any other BU development has been. 10 minutes should be enough for the slower nodes to keep up with plenty of headroom.
No, that's not even nearly enough time, especially not without Segwit. |
|
|
|
This is TECHNICAL SUPPORT Forum, Moderators are here to give Advice, answer question and Solve problems.
False again. The moderators moderate the forum, and do not have to respond to any threads should they chose not to, especially not in this section. You have demonstrated you have no idea what the word Support means. LOL.
You didn't ask for support, you made a thread titled "[TIP]" which gives out false or misleading information at best. Using faster internet access to download 95GB is a false tip? Then you say using a slow internet is Valid?
Again, the download speed is likely not going to be the bottleneck but rather the validation time. Wireless 3Mbps is completly & absolute useless.
Useless != doesn't work. |
|
|
|
|
This topic has been moved to Trashcan.
Reason: Ref. spam.
|
|
|
|
|
Show Posts
