[News]WHY AGAINST SEGWIT AND CORE? Mining investor gives his answer

[jbreher]

Okay, so the BU crowd wants to scale via a hard fork. But why this specific proposal?

It was decided in your absence solely because you left the conversation. You self-selected not to participate. Suck it up, buttercup.

[1713892289]

1713892289

[jbreher]

...  Hearn and Andresen ... whereas the reality is that this whole blocksize debate was began so that they could get their hands on the keys to Bitcoin's source code.

That's not only condescending, but just plain stupid. In the history of Bitcoin, there have been exactly two people who have given up the keys to the castle. One was Satoshi. What was the other one's name...?

[Killerpotleaf]

main community wants segwit!

who are you referring to?

the poeple from the censored forms?
node count?
hashing power?

how can you claim to know what the majority want?

[franky1]

how can you claim to know what the majority want?

even people that love core want dynamic blocksize. the only argument they can come up with though is that they would only TRUST gmaxwell to write the code for it. they are even screaming to tell the community that core never said no to a increase of the base blocksize, they just waiting for gmaxwell who proposed a dynamic blocksize LAST YEAR!

afterall the altcoin dooms day myth has been busted. all that will happen is an elevation of possible orphan rate due to how small or large the minority is (hense 95%+ acceptability to implement). making under 5% (under 250 of 5000 nodes) not sync and need to upgrade.

afterall the bloat doomsday myth has been busted. 4mb bloat is acceptable

so the solution/compromise is obvious. core tweak their segwit code to 2mb base 4mb weight.. call it 0.13.1b release it alongside 0.13.1 and let the community choose to download either 0.13.1 or 0.13.1b

atleast if everyone happily downloads 0.13.1b segwit also gets activated by default too.
if there is no desire of a jump in base block.. then no one will download 0.13.1b and it wont activate. meaning no harm either fanboys just download 0.13.1 instead

but simply preventing even letting the community have the release to even have a choice under their 'trusted' brand they wont run away from. is no longer the right course of action

then. when activated and we have more REAL capacity because the buffer has increased. that gives alot more time to code new features instead of these stupid delays

[DaRude]

main community wants segwit!

who are you referring to?

the poeple from the censored forms?
node count?
hashing power?

how can you claim to know what the majority want?

Are you asking me or franky1? Let me highlight the important parts that you cut out from my quote to make it seem out of context

Only problem is that big blockers realizes that even 20MB blocks cannot accommodate the transaction volume they speak of, nor does it solve 10min confirmation time. So other layers must be implemented which cannot (efficiently) be done without segwit. So they're just trying to hold segwit hostage.

holding it hostage??
um... like core not coding something so holding the other bip hostage by not even having a release available. which is far more hostile then having code released but people choose not to use it.

also are you presume bitcoin is going to jump in utility by a factor of 20, in days, weeks, months, years..?
seems your opinion is that its going to jump in days-months and so your upset that bitcoin cant cope.. yet RATIONALLY bitcoin utility will grow over YEARS and in those YEARS larger blocks would be happily relayable.

the main community is not saying jump to 20mb in weeks-months. its instead asking for a rational growth over rational time without having to beg devs "can i have some more" every couple years. by allowing the growth to be dynamic and not controlled by a team of people paid by banks.

its also worth looking at the bait and switch proposals and who actually proposed them, to then realise that it was done to scare people into loving core

If a space on a distributed blockchain costs only $0.01 i might use it as a notepad to store my reminders. e.g. if it's free (or almost free) to spam i can't imagine mempool being empty again, regardless of the size of a block.

by allowing the growth to be dynamic

Yes sure why don't we introduce this HUGE attack vector into BTC? Sounds like a good plan. No one in their right mind would allow this. How big should a block be to handle Visa volumes?

I like your assumptions of the desires of "main community". I can do that too, main community wants segwit! There is a group that proposed Classic/XT/BU which was/is rejected by the main community. Now there is a proposal for segwit, yet there is a group that is blocking it. So what are the options? Main community must agree with BU minority or otherwise no one gets segwit?

[DaRude]

how can you claim to know what the majority want?

even people that love core want dynamic blocksize. the only argument they can come up with though is that they would only TRUST gmaxwell to write the code for it. they are even screaming to tell the community that core never said no to a increase of the base blocksize, they just waiting for gmaxwell who proposed a dynamic blocksize LAST YEAR!

afterall the altcoin dooms day myth has been busted. all that will happen is an elevation of possible orphan rate due to how small or large the minority is (hense 95%+ acceptability to implement). making under 5% (under 250 of 5000 nodes) not sync and need to upgrade.

afterall the bloat doomsday myth has been busted. 4mb bloat is acceptable

so the solution/compromise is obvious. core tweak their segwit code to 2mb base 4mb weight.. call it 0.13.1b release it alongside 0.13.1 and let the community choose to download either 0.13.1 or 0.13.1b

atleast if everyone happily downloads 0.13.1b segwit also gets activated by default too.
if there is no desire of a jump in base block.. then no one will download 0.13.1b and it wont activate. meaning no harm either fanboys just download 0.13.1 instead

but simply preventing even letting the community have the release to even have a choice under their 'trusted' brand they wont run away from. is no longer the right course of action

then. when activated and we have more REAL capacity because the buffer has increased. that gives alot more time to code new features instead of these stupid delays

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen. If 0.13.1 won't get enabled, bump up blocks to 2MB+segwit and let people vote on that.

[AgentofCoin]

...

...

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen. ...

I don't think it is possible to do actual research on it, it is always a guess (as to node loss).
So besides research on node utilization costs/attacks and block propagation costs/attacks,
the major problem is: no one really can do research on what a post-hardforked blocksize
node count will be. It could be 4500 or it could be 5. There is no way to study it legitimately,
so its outright just a blind risk. I don't like the idea of jumping off a cliff blind and not knowing
if the cliff is deadly or just a simple street curb.

I was thinking today, if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

If I had the know how, that some of the members of this forum have, that is what I would be working on.
Miners don't work for nothing, but node maintainers do. If this puzzle could be legitimately resolved, it would
be a great success for Bitcoin, even more so than a 2 to 8mb blocksize increase.

[franky1]

if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

incentivising them is not easy or even advantageous..

all that will happen is 1-2 corporations running 20,000 nodes all running on AWS each, to grab the incentive.. then the 5000 oldtimers who are left with nothing, will feel that they are not being paid and (unknowingly) think the network is secure with 20,000 nodes.. so they would switch off.

leaving the network in the hands of 1-2 entities and the copies of the blockchain in a centralized single location (amazon service).

the problem with incentives is. rich guys pool their resources to get a leader advantage and claim a majority of incentives.
just take a look at the future industries that 'invested' in trump and now going to become the leaders of their industry with nice large government grants heading their way.

incentives do not mean better security.

[AgentofCoin]

if the BU and other developers figured out a mechanism to "incentivize nodes"
in the same manner that Miners are incentivized to verify Bitcoin txs/blocks, then not only would they
provide one of the greatest services to the Bitcoin community, but also allow a more secured future for
forked upgrades, since the node system can grow and not diminish.

incentivising them is not easy or even advantageous..

all that will happen is 1-2 corporations running 20,000 nodes all running on AWS each, to grab the incentive.. then the 5000 oldtimers who are left with nothing, will feel that they are not being paid and (unknowingly) think the network is secure with 20,000 nodes.. so they would switch off.

leaving the network in the hands of 1-2 entities and the copies of the blockchain in a centralized single location (amazon service).

the problem with incentives is. rich guys pool their resources to get a leader advantage and claim a majority of incentives.
just take a look at the future industries that 'invested' in trump and now going to become the leaders of their industry with nice large government grants heading their way.

incentives do not mean better security.

No, what I meant is figuring out how to create an "incentive node" network that can't be gamed.
This is very hard to do and thus why I said it was a puzzle. But if solved, would be a monumental feat.
If the 5000 oldtimers don't want to join, they don't have to, they can continue as is because they love it.
My reasoning is getting new people into the game because they would be paid to do so.

Bitcoin's blockchain only works because Satoshi knew it needed an incentive to mine.
Mining, as you know, is both verification of transactions and PoW and a systematic dispersal system for the token.
The whole system only works because the miners are "forced" to verify/do work to get the "award/fee".

The proposed incentive for this node network would be very small and not compensate the full cost of a node,
but would allow average people to get bitcoins the same way members of this forum get some bitcoin from
signature campaigns. It may even be possible that the incentive could cover the costs, I haven't done the math.
As the number of "incentive nodes" increase in this proposed network, the incentive shared decreases.
The point is not profit, but to "incentive" people to want to run a node.

When you see how many people sig spam on this forum for their 0.0010 btc or whatever per week or two
(I seriously have no idea how often they are paid and what the average amount is), imagine if all those
people were running this incentive node platform that can't be gamed. It would usher in a new era for Bitcoin.
An era where the Users can be more than just Users, they participate in a way Satoshi originally intended.
Though he understood that over time it would become centralized, I believe he meant around 2050 to 2080
when the system would be institutionalized and not within the first decade of its whitepaper release.

This proposed incentive network would obviously be designed to prevent the exploitation that Franky has
stated as well as others that could occur. Its possible we could make centralized server companies such as
amazon or other cloud storage restricted within this proposed "incentive node" network.
If an attacker wanted to spin up many nodes in a single location, they would need pay the costs of
personally housing those devices and etc, and when the incentive is not substantial, would be a major
financial loss to do. The point is we can design this system if we really wanted to.

Solve the puzzle. Your prize is ensuring a strong future for Bitcoin.

[Carlton Banks]

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen.

I'm not too sure that much research is necessary.



All "4MB weight" means is that in addition to the standard 1 MB blocks we have now, an extra 3 MB can be used but for signatures only. Today's transactions dedicate slightly less than half of their size in bytes to the signature, on average.

And that's why the increase gets quoted as only being between 1.75 MB and 2MB, because it's not possible to fill up all 3 MB of extra block space using transactions that are 1:1 data:signature. The reason there's 3x times more space than we can use is that Lightning transactions will change that average ratio closer to the 1:3 data:signature due to it's use of multi-sig (multi-sig transactions must have larger signatures, as more than one signature is required to sign them correctly).

All this would have to change if the signature technology got changed, which is a likely future upgrade. Bitcoin uses ECDSA signatures right now, but more space-efficient signature schemes exist that could replace it, that would mean the 1:3 data:signature ratio would need changing to reflect that.


So, I hope you can see from this that neither node or mining centralisation is affected by the weighting, it's just a ratio used to target efficient use of block space.

[franky1]

Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen.

the 4mb bloat has been evaluated.
the main cries over the last few years why anything above 1mb was bad was things like
"not everyone has fast internet"
"chinese firewall"
etc

yet all that has been debunked and tests were done that 8mb is acceptable.. but 4mb was deemed the very safe amount to handle for now as acceptable bloat.
"chinese firewall"
yes thats right. while the west was crying that it cant go above 1mb due to chinese firewall.. the east (inside the firewall) all laughed and said what a stupid doomsday. nothing about the chinese firewall has issues with it and data can be so much more than 4mb


"not everyone has fast internet"
tell that to the millions of people in africa doing skype videocalls. then millions of people uploading to youtube. millions doing livestreaming, whilst online gaming...

so devs now backtracked doomsday and happily said upto 4mb bloat was acceptable.

yet still keeping tx baseblock data at 1mb..

i cant wait until they backtrack the 1mb baseblock dooms day when they finally see its just a orphan risk scenario.. hense the need for super high majority consensus to mitigate orphan risk.

the 'it causes altcoin' doomsday is FUD. because oppositions need EXTRA added code to intentionally IP/USERAGENT BAN connecting to certain nodes.. just like ethereum intentionally split '--oppose-dao-fork'
without adding an intentional ban list of IP/useragents. the connected nodes just have an orphan battle on a single chain, they dont keep 2 chains alive for eternity they orphan the minority
high majority consensus means low risk of orphans. and leaves the minority never syncing.. thus again no second chain. just minority left unsynced

as for the "linear/quadratic" doomsday.
easy.

if sigops is causing issues... limit sigops.
there is no rational reason for one person to need to do 500-20000 sigops. so limit the number of sigops a tx can have.
aswell as ensuring validation times are not used as a DDoS, the extra benefit is we will not see a block with just 1tx sized at 1mb with hefty amount of sigops to churn through..