This is under the assumption that the block size wouldn't grow when needed, blocks aren't full without outside attacks so there's no evidence that when the time comes we won't increase the block size to a common sense size.
Well, other than the evidence that blocks were kept small the last time they became persistently full. Which, in itself, is pretty strong evidence. Once the need resurfaces (and it most certainly will), how long do you think it will take to implement the necessary change? That was a short spam attack period, you know damn well that was artificial and everyone knew it. Yes, I remember people posting the addresses of the spammers at the time. That's the good thing about 1mb blocks, spamming gets expensive. Big blocks are a disaster if there isn't sufficient utility. Say you had 32 MB blocks and only < 2 MB of actual traffic. Someone could easily spam 28 MB per block for peanuts. Sustained over 1 day: 4032 MB of garbage for almost free. Good idea indeed. You seem to be postulating some novel mechanism by which one can examine each transaction, and classify it as spam vs. notspam. Care to divulge your criteria? Your dumb arguments about what is "technically" spam and NOT, remains annoying - partly because this is well worn territory in which you have been shown to be attempting to continue to spread misinformation and to detract from the concerted sabotaging (albiet largely unsuccessful except for the purpose of continued FUD spreading) efforts of your Bcash butt buddies. I forget you are often incapable of seeing the obvious*. Without a way to objectively classify an arbitrary tx as spam vs. notspam, any effort to reduce spam by keeping the block size small will -- by necessity -- reduce utility for notspam txs. Reduced utility in direct proportion to the ratio of notspam txs to spam txs. Your approach is counterproductive. *Well, not really. I know full and well your inability to draw rational conclusions from spoonfed data. As well as your propensity to try to finish conversations for others. I still await the honorable and esteemed Lauda's reveal of the criteria to objectively classify an arbitrary tx as spam or as notspam. |
|
|
|
You could keep using your legacy non-segwit coins BUT... I guess you would have some problem forcing other people to send you coins that fulfill your "full legacy trace" requirement. In fact you probably already have that problem, don't you?
Not at all. To a first order approximation (i.e., the overwhelming majority), I have no reason to move BTC in or out. But for those coins that I do move: If someone wants me to pay to their SegWit address, that's no skin off my nose; For inbound, I provide a legacy address to pay to. Easy peasy. Ok. So then if the condition of Bitcoin blocks having a very reasonable 80% peak (maybe hourly averaged) capacity by whatever means, even if that implies only a moderate blocksize increase plus other L2 alleviating solutions... your confidence/preference in Bitcoin would be restored and not keep insisting that BSV is better because: Bigger blocks (even if noone use them), no segwit, no LN, etc? I am just trying to determine if your main concern is only about congestion or if there additional unsolvable (like considering bigger blocks is ALWAYS better) issues here. It would alleviate much of my worries about BTC's future. All things being equal (unfortunately they never are), I have lingering concerns about the way The SegWit Omnibus Changeset was constructed and more concerningly how it was activated. But seeing as we're discussing an unplanned hypothetical, I'm not about to invest in a full analysis. There is also the fact that it is the stated aim of the SV protocol devs that they wish to essentially return the protocol back to that which was bequeathed by satoshi, and then leave it unmolested for all subsequent time (with the caveat that some black swan event may necessitate a change). I see a lot of value in providing a stable platform for other innovation to be built atop, rather than the constant churn and shifting sands endemic to a 'devs gotta dev' mentality at the base layer. But hey - if BTC adopted an attitude that returned them to the economic model that existed from inception until blockapocolypse (namely, block cap always large enough to accommodate the sustained tx demand), that'd take one of the most on-target arrows out of my 'flaws of BTC' quiver now, wouldn't it? |
|
|
|
You could keep using your legacy non-segwit coins BUT... I guess you would have some problem forcing other people to send you coins that fulfill your "full legacy trace" requirement. In fact you probably already have that problem, don't you?
Not at all. To a first order approximation (i.e., the overwhelming majority), I have no reason to move BTC in or out. But for those coins that I do move: If someone wants me to pay to their SegWit address, that's no skin off my nose; For inbound, I provide a legacy address to pay to. Easy peasy. |
|
|
|
Btw imagine bch or bsv having a 51% attack while their communities have preached that hashrate is all that matters.
I don't see what you are getting at. Doing such would seem to validate the hypothesis. You really believe the bch or bsv community wouldn't throw fits during a 51% attack instead of saying well that just means we didn't have enough hash? A 51% 'attack' is merely evidence that 'the community' did not realize that the actual community was a group other than that which they assumed. Btw what coin would you follow if they both did forks and revert the 51% attacks ?
I'm not sure I understand your question - care to rephrase? I in no way can see you standing for a reversal of transactions.
At the risk of repeating myself: chain reorgs do not reverse transactions. I'm saying that if there is a successful 51% attack and the community decides to do a fork at the time before the transactions, where would you stand? Well, that could depend upon any number of collateral situations. But my initial knee-jerk reaction would be to follow the chain with the preponderance of hash rate. How do you discern a 51% 'attack' as opposed to all situations normal? |
|
|
|
Was that supposed to sting or something?
Yes. Too bad, so sad. Your intent to kick another when 'down' was ineffectual. |
|
|
|
Neither. United States financial regulator, the Securities and Exchange Commission (SEC) has taken action and forced a temporary suspension of trading in the securities of crypto exchange Bitcoin GenerationAlmost sounds of if they are suspending trading of the securities that represent ownership in 'Bitcoin Generation' as an entity to itself. |
|
|
|
Btw imagine bch or bsv having a 51% attack while their communities have preached that hashrate is all that matters.
I don't see what you are getting at. Doing such would seem to validate the hypothesis. You really believe the bch or bsv community wouldn't throw fits during a 51% attack instead of saying well that just means we didn't have enough hash? A 51% 'attack' is merely evidence that 'the community' did not realize that the actual community was a group other than that which they assumed. Btw what coin would you follow if they both did forks and revert the 51% attacks ?
I'm not sure I understand your question - care to rephrase? I in no way can see you standing for a reversal of transactions.
At the risk of repeating myself: chain reorgs do not reverse transactions. |
|
|
|
Btw imagine bch or bsv having a 51% attack while their communities have preached that hashrate is all that matters.
I don't see what you are getting at. Doing such would seem to validate the hypothesis. Makes sense. I got a question for you... if Bitcoin increased its blocksize so that PEAK usage would be under 80% capacity... would you reconsider your current preference of BSV over Bitcoin or would you still be insisting in BSV to be a better choice because of... donno... "way bigger" blocks and no segwit/LN support? Hmm. Lot of dependencies. It would certainly make the situation vastly improved in my mind. Peak under 80% capacity would eliminate the persistently-full block state - so that's goodness. But how would this sliding block cap be regulated? Who has their hands on the lever? How realistic will it remain to deal only in coins that have never been through a SegWit address? |
|
|
|
BTC 8 tps
BCH 80 tps
BSV 800 tps
There are shitcoins with over 10k tps. Should we dump BSV for them? Not traceable to the satoshi genesis? Such would be unwise. YMMV. |
|
|
|
Decision is fully yours. Own it.
Hows that working out for you bear? So far? Suboptimal. Yet in this moment, I am serene. Owning it?
Yup. Fully. What's it to you? Was that supposed to sting or something? ...bubye
Umm... you leaving? |
|
|
|
Btw imagine bch or bsv having a 51% attack while their communities have preached that hashrate is all that matters.
I don't see what you are getting at. Doing such would seem to validate the hypothesis. |
|
|
|
Larger blocks are inanimate. Regardless of size, blocks do not have the power to 'push (so-called) nodes off' of anything. Bitcoin does not owe you a position in its network. Either expend the resources required, or drop to the side in your inability to keep up. Decision is fully yours. Own it.
a race to the bottom? No. A race to the top. just how big a datacenter and monthly cost will eventually be needed to run bsv with its "everything including the kitchen sink" philosophy? to the point only billionaires and humongous companies etc can afford it?
is there any upper limit? i am genuinely curious.
Well, there's currently an upper limit that is not too atrocious. The story for the future is no upper limit. Implicit in your question would seem to be the philosophy that the system should be limited in order to allow those with no skin in the game to be first-class citizens. Why do you believe this to be appropriate? You would think that those that abdicated the mining to those willing to take the risk would have learned this lesson already. |
|
|
|
Bitcoin increases blocksize and shows it was indeed needing to have larger blocks (which then are filled with nonsense and can push nodes off)
Larger blocks are inanimate. Regardless of size, blocks do not have the power to 'push (so-called) nodes off' of anything. Bitcoin does not owe you a position in its network. Either expend the resources required, or drop to the side in your inability to keep up. Decision is fully yours. Own it. Cool so how about if someone spammed Bchsv (I think that's the shitcoin flavor you're favoring now) Hmm. Don't know. I'm not aware of any coin that is routinely referred to as the moniker 'Bchsv'. I suppose you mean Bitcoin-SV? I must admit that my most-used abbreviation of 'SV" is non-standard as well, with the most common ticker being 'BSV'. Oh well, I'll just assume that's what you refer to. and pumped out multiple spam attacks to the 128mb blocks for only 1 week. Now that would be an increase of 129gb. Let's say some bad actor like Roger came and kept at it (like he did to btc) and kept I up for let's say 2 months.
If, indeed, the mimers included all those txs. As those with the most non-liquid investment on the line, we trust the miners with enough rope to shoot themselves in the foot. They're not going to make blocks big enough to alienate the economic majority. OTOH, it does kind of lay bare the lie promulgated by The Wizards Of Core [tm], who pronounced that block size increases were impossible. That's an extra 1.032 Terabyte, that's not too much to handle
'zackly but i bet you'd have those on the bsv subreddits and forums complaining that they can't keep up, and being mad about spam.
Of course. Bitcoin Core does not have a monopoly on overly-entitled whiners. Especially since that community is moreso mad broke kids who missed out on real btc and want a redo.
I think you are grievously mistaken. While anecdotal, the evidence I have seen suggest that there is a higher percentage of well-capitalized Bitcoin OGs in the big block corner than there is in the BTC camp. TBH a bad actor could easily inflate bsv to 6.7 terabyte a year
Oh. Emm. Gee. exclamation_point. I'd have to pay ... umm ... $160 in order to store all that. The horror. Of course, it would again require the cooperation of at least half the mining hash power. Otherwise, less storage needed. |
|
|
|
Bitcoin increases blocksize and shows it was indeed needing to have larger blocks (which then are filled with nonsense and can push nodes off)
Larger blocks are inanimate. Regardless of size, blocks do not have the power to 'push (so-called) nodes off' of anything. Bitcoin does not owe you a position in its network. Either expend the resources required, or drop to the side in your inability to keep up. Decision is fully yours. Own it. BTC will not be able to increase the block size because in this case it will have to cancel the Seqwit, which will not allow the signed transactions from Satoshi's wallets to work in January 2020 I think you are mistaken. I know of no technical limitation that makes SegWit incompatible with a future block size increase. |
|
|
|
I've seen some very nice hats that are not worn and are not in the signing campaign ..., jbreher!  Do you need new glasses? |
|
|
|
Keeping blocks small shifts the balance in favor of Type 1, preventively.
By what mechanism? By pissing off the spammers. Not sure if serious. I don't quite see how raising the ire of The Bad Guys is any sort of basis for network security. If anything, it would seem counterproductive. |
|
|
|
Bitcoin increases blocksize and shows it was indeed needing to have larger blocks (which then are filled with nonsense and can push nodes off)
Larger blocks are inanimate. Regardless of size, blocks do not have the power to 'push (so-called) nodes off' of anything. Bitcoin does not owe you a position in its network. Either expend the resources required, or drop to the side in your inability to keep up. Decision is fully yours. Own it. |
|
|
|
You seem to be postulating some novel mechanism by which one can examine each transaction, and classify it as spam vs. notspam. Care to divulge your criteria?
We've been over this already haven't we. Type 1. Legit transaction. The actor needs to move funds because the funds are needed to be elsewhere. Type 2. Spam transaction. The actor wants to move funds for other collateral effects, such as clogging the queue. I admit there is no easy criterion to tell one from the other onchain, after the fact. QFT. Keeping blocks small shifts the balance in favor of Type 1, preventively.
By what mechanism? |
|
|
|
Hoan Kiem Lake is famous because a turtle god lives in it that gave the Vietnamese emperor a sword to fight off Chinese invaders.
Listen -- strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. ... Well you can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you! - Dennis |
|
|
|
This is under the assumption that the block size wouldn't grow when needed, blocks aren't full without outside attacks so there's no evidence that when the time comes we won't increase the block size to a common sense size.
Well, other than the evidence that blocks were kept small the last time they became persistently full. Which, in itself, is pretty strong evidence. Once the need resurfaces (and it most certainly will), how long do you think it will take to implement the necessary change? That was a short spam attack period, you know damn well that was artificial and everyone knew it. Yes, I remember people posting the addresses of the spammers at the time. That's the good thing about 1mb blocks, spamming gets expensive. Big blocks are a disaster if there isn't sufficient utility. Say you had 32 MB blocks and only < 2 MB of actual traffic. Someone could easily spam 28 MB per block for peanuts. Sustained over 1 day: 4032 MB of garbage for almost free. Good idea indeed. You seem to be postulating some novel mechanism by which one can examine each transaction, and classify it as spam vs. notspam. Care to divulge your criteria? |
|
|
|
|
Show Posts
