The Blocksize Debate & Concerns - page 10.

AliceGored

member

Activity: 117

Merit: 10

Quote from: ziiip on June 26, 2016, 06:55:26 PM

Quote from: AliceGored on June 26, 2016, 06:50:53 PM

Quote from: ziiip on June 26, 2016, 06:25:20 PM

Quote from: AliceGored on June 26, 2016, 06:20:15 PM

Quote from: Carlton Banks on June 26, 2016, 06:07:52 PM

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: AliceGored on June 26, 2016, 06:50:53 PM

Quote from: ziiip on June 26, 2016, 06:25:20 PM

Quote from: AliceGored on June 26, 2016, 06:20:15 PM

Quote from: Carlton Banks on June 26, 2016, 06:07:52 PM

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

member

Activity: 117

Merit: 10

Quote from: ziiip on June 26, 2016, 06:25:20 PM

Quote from: AliceGored on June 26, 2016, 06:20:15 PM

Quote from: Carlton Banks on June 26, 2016, 06:07:52 PM

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: AliceGored on June 26, 2016, 06:20:15 PM

Quote from: Carlton Banks on June 26, 2016, 06:07:52 PM

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

member

Activity: 117

Merit: 10

Quote from: Carlton Banks on June 26, 2016, 06:07:52 PM

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: ziiip on June 26, 2016, 05:44:46 PM

Quote from: Carlton Banks on June 26, 2016, 05:37:19 PM

Quote from: ziiip on June 26, 2016, 05:26:12 PM

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?

Quote from: Carlton Banks on June 26, 2016, 05:53:43 PM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: AliceGored on June 26, 2016, 05:59:29 PM

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

https://bitcointalksearch.org/topic/m.7687

https://bitcointalksearch.org/topic/m.8810

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: RocketSingh on June 20, 2016, 06:17:15 PM

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

Quote from: gmaxwell on June 21, 2016, 02:05:29 AM

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?

AliceGored

member

Activity: 117

Merit: 10

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

https://bitcointalksearch.org/topic/m.7687

https://bitcointalksearch.org/topic/m.8810

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: ziiip on June 26, 2016, 05:44:46 PM

Quote from: Carlton Banks on June 26, 2016, 05:37:19 PM

Quote from: ziiip on June 26, 2016, 05:26:12 PM

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.

Quote from: ziiip on June 26, 2016, 05:44:46 PM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: franky1 on June 26, 2016, 02:54:41 PM

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

ziiip

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: Carlton Banks on June 26, 2016, 05:37:19 PM

Quote from: ziiip on June 26, 2016, 05:26:12 PM

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

legendary

Activity: 3430

Merit: 3080

Quote from: ziiip on June 26, 2016, 05:26:12 PM

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: Lauda on June 26, 2016, 05:20:40 PM

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?

Quote from: Lauda on June 26, 2016, 05:00:47 PM

Quote from: ziiip on June 26, 2016, 04:57:11 PM

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

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: ziiip on June 26, 2016, 05:13:37 PM

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

full member

Activity: 255

Merit: 102

uBlock.it Admin

Quote from: Carlton Banks on June 26, 2016, 04:59:37 PM

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.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: ziiip on June 26, 2016, 04:57:11 PM

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.

beastmodeBiscuitGravy

full member

Activity: 181

Merit: 100

Quote from: ziiip on June 26, 2016, 04:57:11 PM

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

Because Gregory said so. QED.

Why do you insist on attacking broad and uncontentious consensus like this?

Carlton Banks

legendary

Activity: 3430

Merit: 3080

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

ziiip

full member

Activity: 255

Merit: 102

uBlock.it Admin

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

Topic: The Blocksize Debate & Concerns - page 10. (Read 11213 times)