The Blocksize Debate & Concerns

[ziiip]

No, because one way or another, it's going up. There is no argument to be had, except the same tired old "b-b-but main chain 2MB" stuff. Knock yourself out, but I'm not interested

lol I'm talking about one line of code to help fulfill demand by users for faster confirmation times.
If everyone agrees that blocks should be larger, then please tell me why changing one line of code is a bad idea.

[1715004577]

1715004577

[1715004577]

1715004577

[Lauda]

lol I'm talking about one line of code to help fulfill demand by users for faster confirmation times. If everyone agrees that blocks should be larger, then please tell me why changing one line of code is a bad idea.

If you think that it is 'one line of code' then you really don't know what you're talking about. Take a look at how many lines of code Gavin's BIP has and then come here. A 2 MB block size limit is not safe on its own. If it were, then Classic would have not added those limitations.

[ziiip]

If you think that it is 'one line of code' then you really don't know what you're talking about. Take a look at how many lines of code Gavin's BIP has and then come here. A 2 MB block size limit is not safe on its own. If it were, then Classic would have not added those limitations.

How many 'lines of code' are included in segwit?

Does anyone care to argue ANY valid point's regarding why a blocksize increase is a bad idea?

Quick and short list:

• Network has practically no hard fork experience.
• 2 MB block size limit is unsafe due to quadratic validation time - Gavin's BIP for Classic adds additional limitations to prevent this.
• Does not improve scalability at all.
• Does not come with any benefits besides increased TPS either.

This has all been discussed over and over in various places. This is why Segwit is the next step, it will make validation time linear among other things. I can't say whether and when a potential block size increase is going to come after Segwit.

How is scalability not improved with TPS increase?
Since everyone agrees that we will need a blocksize increase regardless of segwit, should we just wait until the network is has "more hard fork experience" ? lol

[Carlton Banks]

How is scalability not improved with TPS increase?

Because scalability and TPS are not synonymous metrics. Scalability includes a whole bunch of other factors, throughput is only one. Increasing the blocksize only improves 1 factor: the throughput (i.e. TPS). And it does so at the expense of all other factors: hence, does not constitute a scaling solution

[ziiip]

How is scalability not improved with TPS increase?

Because scalability and TPS are not synonymous metrics. Scalability includes a whole bunch of other factors, throughput is only one. Increasing the blocksize only improves 1 factor: the throughput (i.e. TPS). And it does so at the expense of all other factors: hence, does not constitute a scaling solution

What metric would like to see used when referring to scalability? I'm pretty sure that more TPS will certainly provide additional scalability. The block propagation time issue has already been addressed by Xthin /compact blocks. What else is there really to be concerned with?

[Carlton Banks]

please stop making corporate paid coders into messiahs.. its not healthy for you

franky, you cannot be serious. You're actually biting my style! Go home, you're so done, lol. That's like the most absolute victory, you're actually trying to run my lines: on me! ahhhhahhahhhhhaaahhhaaaaaaa. haha. That's priceless, do another one lol

[Carlton Banks]

How is scalability not improved with TPS increase?

Because scalability and TPS are not synonymous metrics. Scalability includes a whole bunch of other factors, throughput is only one. Increasing the blocksize only improves 1 factor: the throughput (i.e. TPS). And it does so at the expense of all other factors: hence, does not constitute a scaling solution

What metric would like to see used when referring to scalability? I'm pretty sure that more TPS will definitely help provide more scalability.

Proclivities have nothing to do with it. This is about reality. And they're different expressions. With different meainings. That's why they're spelled different, to help you differentiate between the two.

The block propagation time issue has already been addressed by Xthin and compact blocks. What else is there really to be concerned with?

Xthin is flawed, gmaxwell found a hash collision bug in xthin, GTFO with that garbage. Another major issue is node distribution, and there is no good metric for that.

[AliceGored]

Contrast the system of "holy 1MB protecting decentralization", with satoshi's actual thoughts on the matter...    


https://bitcointalk.org/index.php?topic=287.msg7687#msg7687


https://bitcointalk.org/index.php?topic=287.msg8810#msg8810

My, how far we've fallen down the Maxwellian rabbit hole.

[ziiip]

Malleability is already fixed. Segwit does not fix it further.

Technical point: This is very much not the case: Malleability is blocked in the relay network for a narrow class of transactions but anything clever is exposed, multisig is exposed to other-signer malleation, and all transactions are exposed to malleation by miners. Segwit fixes it in a deep and profound way for all purely segwit transactions.

What relay network are we referring to here?
Does segwit still not provide a solution to malleation by miners for on-chain transactions? Just curious because it sound's Malleability is only "blocked" on the "relay" network. How is consensus enforced in this relay network?  Can i run a "relay network" node? Is the "relay network" open sourced?

[Carlton Banks]

Contrast the system of "holy 1MB protecting decentralization", with satoshi's actual thoughts on the matter...    


https://bitcointalk.org/index.php?topic=287.msg7687#msg7687


https://bitcointalk.org/index.php?topic=287.msg8810#msg8810

My, how far we've fallen down the Maxwellian rabbit hole.

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

[ziiip]

How is scalability not improved with TPS increase?

What metric would like to see used when referring to scalability? I'm pretty sure that more TPS will certainly provide additional scalability. The block propagation time issue has already been addressed by Xthin /compact blocks. What else is there really to be concerned with?

Proclivities have nothing to do with it. This is about reality. And they're different expressions. With different meainings. That's why they're spelled different, to help you differentiate between the two.

The reality is you still have not answered my question. What else is there really to be concerned with? Other than items we have listed here, e.g. compact blocks etc.

[AliceGored]

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

Yes, you did say it. I’m glad you did, it helps explain the psyche of the mini-blocker.

Let’s just hope that when “some bloke” > gregory maxwell > satoshi shows up… they don’t go found a VC/legacy finance funded operation with confessed scammer Austin D. Hill to siphon utility and revenue away from the native Bitcoin network, again.

[ziiip]

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

Yes, you did say it. I’m glad you did, it helps explain the psyche of the mini-blocker.

Let’s just hope that when “some bloke” > gregory maxwell > satoshi shows up… they don’t go found a VC/legacy finance funded operation with confessed scammer Austin D. Hill to siphon utility and revenue away from the native Bitcoin network, again.

gmaxwell has still not resolved the malleability issue for ON CHAIN TRANSACTIONS

[AliceGored]

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

Yes, you did say it. I’m glad you did, it helps explain the psyche of the mini-blocker.

Let’s just hope that when “some bloke” > gregory maxwell > satoshi shows up… they don’t go found a VC/legacy finance funded operation with confessed scammer Austin D. Hill to siphon utility and revenue away from the native Bitcoin network, again.

gmaxwell has still not resolved the malleability issue for ON CHAIN TRANSACTIONS

If you mean non-segwit transactions = on chain transactions, this could be true, I guess.
[Ironically it wouldn't be if segwit was done without the opcode hack and as a HF.]

But he (really his coworker, and contractor, Pieter and luke-jr) HAS solved on chain + segwit malleability, which is critical for payment channel smart contract use of the chain. So you see how Core development really works... everything that Blockstream wants/needs is done straight away (BIP9, CSV, SFSW), while even planning for a small capacity HF over a year away is indefinitely shelved.

[ziiip]

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

Yes, you did say it. I’m glad you did, it helps explain the psyche of the mini-blocker.

Let’s just hope that when “some bloke” > gregory maxwell > satoshi shows up… they don’t go found a VC/legacy finance funded operation with confessed scammer Austin D. Hill to siphon utility and revenue away from the native Bitcoin network, again.

gmaxwell has still not resolved the malleability issue for ON CHAIN TRANSACTIONS

If you mean non-segwit transactions = on chain transactions, this could be true, I guess.
[Ironically it wouldn't be if segwit was done without the opcode hack and as a HF.]

But he (really his coworker, and contractor, Pieter and luke-jr) HAS solved on chain + segwit malleability, which is critical for payment channel smart contract use of the chain. So you see how Core development really works... everything that Blockstream wants/needs is done straight away, (BIP9, CSV), while even planning for a small capacity HF over a year away is indefinitely shelved.

The main point here is that Bitcoin transaction malleability has never been fixed. ONLY segwit malleability has been fixed, and segwit doesn't even exist yet. . .

[AliceGored]

gmaxwell > satoshi. Yeah, I said it.

There were some really serious bugs in Satoshi's code; who fixed those bugs? Core team. Give it up, Satoshi was inspired, but not the Second Coming. Someone better than Peter Todd or gmaxwell will turn up one day, too. Inspired by all of them; ruled by none of them

Yes, you did say it. I’m glad you did, it helps explain the psyche of the mini-blocker.

Let’s just hope that when “some bloke” > gregory maxwell > satoshi shows up… they don’t go found a VC/legacy finance funded operation with confessed scammer Austin D. Hill to siphon utility and revenue away from the native Bitcoin network, again.

gmaxwell has still not resolved the malleability issue for ON CHAIN TRANSACTIONS

If you mean non-segwit transactions = on chain transactions, this could be true, I guess.
[Ironically it wouldn't be if segwit was done without the opcode hack and as a HF.]

But he (really his coworker, and contractor, Pieter and luke-jr) HAS solved on chain + segwit malleability, which is critical for payment channel smart contract use of the chain. So you see how Core development really works... everything that Blockstream wants/needs is done straight away, (BIP9, CSV), while even planning for a small capacity HF over a year away is indefinitely shelved.

The main point here is that Bitcoin transaction malleability has never been fixed. ONLY segwit malleability has been fixed, and segwit doesn't even exist yet. . .

Well, to match you in a little pedantry...

That's more of a declarative than a point, really.

[ziiip]

Well, to match you in a little pedantry...

What are you even talking about?

[AliceGored]

Well, to match you in a little pedantry...

What are you even talking about?

I’m saying your point wasn’t sufficiently sharpened.

Malleability isn’t an actual problem for most applications. Where it is a problem, for LN type payment contracts, it can be fixed by segwit, which they will use. So, while you declared a true statement in the snapshot of today, you didn’t follow with what that means for us… which explains the blunt tip of your reply. 

[ziiip]

I’m saying your point wasn’t sufficiently sharpened.

Malleability isn’t an actual problem for most applications. Where it is a problem, for LN type payment contracts, it can be fixed by segwit, which they will use. So, while you declared a true statement in the snapshot of today, you didn’t follow with what that means for us… which explains the blunt tip of your reply.  

If malleability is not an actual problem, then what is segwit good for? A scalability solution? At the end of the day someone still has to relay segwit transactions. Why should we need to run a relay network node and a bitcoin network node? Is there any incentive to run a Lightning Network node?

Edit: I understand that segwit provides the possibility for things like payment channels etc. But why is it being touted as a scaling solution for BITCOIN, knowing that segnet and Bitcoin are two different things. I think the topic of this thread is about The BITCOIN blocksize debate unless i misread the title. . .

[AliceGored]

I’m saying your point wasn’t sufficiently sharpened.

Malleability isn’t an actual problem for most applications. Where it is a problem, for LN type payment contracts, it can be fixed by segwit, which they will use. So, while you declared a true statement in the snapshot of today, you didn’t follow with what that means for us… which explains the blunt tip of your reply. 

If it's not an actual problem, then what is segwit good for besides moving transactions off chain? At the end of the day someone still has to relay them. . .

Just because one has a problem with the way LN type payment contracts are being economically favored through the central planning of a static maxblocksize... doesn't mean one has to / should be against them totally.

Let's face it, they are a breakthrough that really could be a serious force multiplier for Bitcoin. Segwit brings big benefits too in terms of validation costs, it's more than just malleability.

I'm for fair competition of different solutions, on-chain/off-chain/hybrids, etc... I only complain about the economic incentives being tilted in favor of a "chosen" solution by an infallible priesthood of Core devs.