Roger Ver has been compromised

[jonald_fyookball]

 I have never mentioned nor denied bandwidth growth.

Good, troll.

Putting you on ignore for a while.  This thread is a great example of your troll tactics
for all to see.  No need to waste further time on you for now.

[1714993279]

1714993279

[1714993279]

1714993279

[1714993279]

1714993279

[1714993279]

1714993279

[1714993279]

1714993279

[Quickseller]

You are wrong. There are plenty of systems out that, even a minor hiccup would cause economic disruptions greater than the total market value of bitcoin currently in just a few days.

Most of those systems (if not I dare all) are not based on 1 location and would require simultaneous outages of clusters. The chances of that are extremely slim (see why e.g. FB, which is not such a system, doesn't even go down world wide due to huge scale DDoS or other disruption world wide, it usually goes down for certain regions). "In just a few days"? Bitcoin would be dead.

So you go from "Bitcoin failing would be worse than other systems failing" to "Bitcoin is vulnerable, so we can't make it useable"

Railroad networks is a good example of a system that contradicts your point. The same is true with GPS technology.

The 'discount' to signature space that SW gives picks winners and losers.

No.

Yes, it does. LN is signature heavy (roughly 4x as much signature space is required to open a LN channel as traditional single private key transactions currently require), and are chosen to be a winner via SegWit.

[franky1]

segwit dos not solve quadratics.. it makes it 4x worse:
0.12 4k maxtxsigops (~10sec validation time)
0.14 16k maxtxsigops (~8min validation time)

This is unadulterated jibberish technobabble.

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

The consensus rule for non-segwit signature operations is 20k before segwit and not changed (it can't be increased by segwit as that would be a hardfork), and segwit transactions are much faster to hash (on average and especially in the worst case where they are thousands of times faster).

I am only responding to this habitually dishonest bullshitter because his comments have been quoted in the media.

look at the word twisting..

1.
" a block that has even 1 segwit tx takes less time to verify then the worse case block with no segwit"
- no sh*t sherlock but what about BEST case block with no segwit,
- i could also hint at asking you to also factor in the extra time needed to strip the block ready to relay to a downstream non-segwit node but ill bite my lip and laugh at the one error in your word twisting for now

2. The consensus rule for non-segwit signature operations is 20k before segwit
- hmm.. thats BLOCK consensus before segwit...  but tx sigops is policy not consensus... but anyways.. but what about AFTER segwit activates
  for both block and tx.. as i said TXsigops is 16k

3. spammers are not going to voluntarily move their funds to use segwit keypairs to stupidly disarm themselves from quadratics.
so even if say 99.9% of people do move (the innocent crowd).. spammers only need to create 5 tx's to cause issues..
put it this way would you walk into the ganglands of some new york 'hood and ask the 'gangsta's to use flowers and not guns, thinking they would happily comply.
wake up, spammers want to spam so they wont disarm themselves. but you G1megmax have not helped the situation

[Lauda]

So you go from "Bitcoin failing would be worse than other systems failing" to "Bitcoin is vulnerable, so we can't make it useable"

You didn't even understand my post.

Railroad networks is a good example of a system that contradicts your point. The same is true with GPS technology.

The examples are not valid (the whole railroad network won't fail all at once, and GPS reliance is also about to dissipate in certain places with GALILEO; GLONASS ensures a non completely global failure in the case of GPS failing). If Bitcoin experiences downtime, then we are experiencing complete network failure.

Yes, it does. LN is signature heavy (roughly 4x as much signature space is required to open a LN channel as traditional single private key transactions currently require), and are chosen to be a winner via SegWit.

Both P2WPKH and P2WSH are "winners". There are only losers if you twist everything upside down and insist on using the outdated transaction designs.

[jonald_fyookball]

look at the word twisting..
 

this is Gmax's MO when it comes to discussing scaling issues...
swoop in, post something true but incomplete/tangential/diversionary
while implying you don't know what you're talking about (he's gmax of course),
and then leave without actually debating the point (why would he, he's
a busy core developer and obviously much smarter than you).

Same thing happened when I left comments about UASF.
https://bitcointalk.org/index.php?topic=1871762

[franky1]

other word twisting from gmax

about how 3 year old hardware is causing issues for his 6month old software.. (im laughing at the illogic of gmaxwels time travel theory of going back in time to create hardware to attack software)

.. its much like blaming aTI's opencL for having efficiency gains vs geforce in the gpu mining days.. but then some dev makes some code years later and realises that the software wont work with open CL so would blame openCL

Because Segwit effs up the block architecture at such a low level...

The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.

it doesnt F up the block architecture. you just have to find a different way of doing things.
you took a short cut using the backdoor luke highlighted in 2015. and last month you realised you hit a wall where the shortcut was a deadend

in future dont waste 1.5 years with shortcuts when doing a proper community desiring node+pool approach would get everything everyone wants without delay, debate and frustration in less time

EG
if you want to mess around with no witness, prunned, etc.. just make that a new brand. call it core lite, let the multibit/electrum guys play with that as a dev project

then YOU could concentrate on a network of proper full node network, not ways to dilute the full node count with all the going soft pretense of "aww its ok to waste 2 years for a messy 2 level (upstream tier nodes) and down stream filtered/stripped/pruned topology."

think about it
if in late 2015 you just done a release that would have been a proper NODE consensus of a single merkle design 4mb block. you would have had MORE than 80% acceptance of nodes by now. and a community that would have been happy. and no drama and no asic boost blaming for why segwit soft attempt has issues. (because there wouldnt have been a 2merkle approach)

[anonymoustroll420]

over word twisting from gmax

about how 3 year old hardware is causing issues for his 6month old software.. (im laughing at the illogic of gmaxwels time travel theory of going back in time to create hardware to attack software)

.. its much like blaming aTI's opencL for having efficiency gains vs geforce in the gpu mining days.. but then some dev makes some code years later and realises that the software wont work with open CL so would blame openCL

ASICBOOST isn't an efficiency gain.

Lets take a few hypothetical scenarios:

All ASIC's move from 28nm tech to 16nm tech.
-More work is being done, therefore more security

ASICBOOST is released for free and all ASIC's adopt it
-Same amount of work is being done, security is the same

ASICBOOST is patented and only specific miners can use it
-Same amount of work is being done, but causes miner centralization.

Bitcoin's security is provided by work (proof of work). Actual work has to be done to increase security. "Shortcuts" do not increase security. ASICBOOST doesn't do more work, it lets you pretend that you did more than you actually did. It is not an efficiency gain, it is a shortcut. It is disenguous to compare it to AMD vs Nvidia or other efficiency gains where more work was done.

[franky1]

ASICBOOST isn't an efficiency gain.

Lets take a few hypothetical scenarios:

All ASIC's move from 28nm tech to 16nm tech.
-More work is being done, therefore more security

ASICBOOST is released for free and all ASIC's adopt it
-Same amount of work is being done, security is the same

ASICBOOST is patented and only specific miners can use it
-Same amount of work is being done, but causes miner centralization.

Bitcoin's security is provided by work (proof of work). Actual work has to be done to increase security. "Shortcuts" do not increase security. ASICBOOST doesn't do more work, it lets you pretend that you did more than you actually did. It is not an efficiency gain, it is a shortcut. It is disenguous to compare it to AMD vs Nvidia or other efficiency gains where more work was done.

im laughing..

imagine it this way.
imagine if gmax refused to let ATI and asic boost use their efficiency gains..
then some hacker group or government decided to use it instead...

would you prefer that pools within bitcoin were using the best efficiency to secure bitcoin against outsiders. or
tell OUR pools to slowdown or  F off so that:
1 gmax can use backdoor exploits(the going soft has been admitted as a backdoor) to push in features without needing node consensus
and
2. allow outsiders to then use asic boost and previously openCL to be 20% more efficient, than pools that have been running for years.

would you actually be happy if 2011-2013 was just Geforce mined and then asic mined using a method that was 20% less efficient then some outside group could do it.

in my eyes
dont let gmax get away with excuses of why his 6 month old software just isnt up to par... just because they wasted a year building it that way.

instead he should have just done a single merkle full node+pool consensus back at the end of 2015 and close the options of going soft, aswell as adding in the other community feature desires in 18 months so that by now we would have had a happy united network of over 90%+ of nodes ready..

im still laughing at how he wants to make it so the network allows changes in 'softly' even easier in future.. come on atleast that should wake you up to the critical thinking of it being used by outsiders to trojan horse in bad features..

even if you are a blockstream devotee, you have to see the risks of 'if X can be implemented without changing nodes' it's a trojan risk even if blockstream are not the ones doing it.
wake up.

[anonymoustroll420]

I made a full thread about this explaining in more detail:
https://bitcointalk.org/index.php?topic=1876148

then some hacker group or government decided to use it instead...

Switching from CPU's to GPU's did more work, this is not an exploit.

A hacker or government using a cryptographic attack that allows them to pretend they did more work than they did would be an exploit. Just like any other exploit found, it would be patched.

would you prefer that pools within bitcoin were using the best efficiency to secure bitcoin against outsiders

It's an exploit, doesn't provide security.

dont let gmax get away with excuses of why his 6 month old software just isnt up to par... just because they wasted a year building it that way.

I never mentioned segwit in that post. It had nothing to do with segwit. It had to do with a cryptographic attack (colliding message blocks) which reduces the security of sha-256 from 2^256 to 2^255.48. Read my full thread.

[franky1]

I made a full thread about this explaining in more detail:
https://bitcointalk.org/index.php?topic=1876148

then some hacker group or government decided to use it instead...

Switching from CPU's to GPU's did more work, this is not an exploit.

the gpu days
there was Geforce (GPU) and ATi(GPU)
saying ATi should not mine because they were using openCL on thier GPU's simply because its unfair to Geforce. and arguing that ATi are exploiting and attacking bitcoin... now that would have been FUD

its was better to have ATi on our side to make blocks quicker to then increase the difficulty. to secure the blockchain. rather then throw them under the bus and say geforce only.. to later have some outsider grab all the ATi cards and over power the network.

yea Geforce didnt get many sales in the bitcoin market but we certainly secured the bitcoin network better because of ATi..

same is for ASICS.
so, which is more important? let btcc get more sales. or have a network with upto 20% more difficulty effect (security) working for us instead of against us.

all because some 6 month software that tried bypassing node consensus hit a hurdle in that bypass, with such hardware+software that has existed for years.

A hacker or government using a cryptographic attack that allows them to pretend they did more work than they did would be an exploit. Just like any other exploit found, it would be patched.

you keep thinking its 'pretending to do work'
the hashes match. they do the work they just do it in a way thats quicker than others

im laughing that in a restaurant. you would rather have the chef make customers wait an hour instead of 48 minutes. just to say ' its taking longer because there is only one way to cook a steak. the chef is rubbing it against his butcheeks to ensure it stays tender while having the steak being warm enough to not 'moo' at customers if they stuck a fork in it.

so here goes.

an exploit is where you find a way that MD5 becomes accepted hash instead of sha (giving a customer a mincemeat patty instead of steak)

an efficiency gain is where the end result is an actual sha as expected (an actual steak) that passes the sha test(cooked to customers request) and has simply done it in less time due to a technique that can help strengthen the network(cooked on a grill instead of rubbed on buttcheeks)...

whats next gmax proclaim bitcoin should only be sha'd using raspberry pi's. and let the difficulty become easily attackable by outsiders that choose to use asics..
or.. critically allow asics to do things most efficiently and the devs do a proper job by recoding their new unactivated software that wont hit hurdles

[The One]

over word twisting from gmax

about how 3 year old hardware is causing issues for his 6month old software.. (im laughing at the illogic of gmaxwels time travel theory of going back in time to create hardware to attack software)

.. its much like blaming aTI's opencL for having efficiency gains vs geforce in the gpu mining days.. but then some dev makes some code years later and realises that the software wont work with open CL so would blame openCL

ASICBOOST isn't an efficiency gain.

Lets take a few hypothetical scenarios:

All ASIC's move from 28nm tech to 16nm tech.
-More work is being done, therefore more security = greater efficiency in terms of costs v profit by creating higher BTC value.

ASICBOOST is released for free and all ASIC's adopt it
-Same amount of work is being done, security is the same

ASICBOOST is patented and only specific miners can use it
-Same amount of work is being done, but causes miner centralization.

Bitcoin's security is provided by work (proof of work). Actual work has to be done to increase security. "Shortcuts" do not increase security. ASICBOOST doesn't do more work, it lets you pretend that you did more than you actually did. It is not an efficiency gain, it is a shortcut. It is disenguous to compare it to AMD vs Nvidia or other efficiency gains where more work was done.

[jbreher]

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

Really? You're telling me that it is possible to construct a block with a single SegWit transaction that might be less resource intensive than the largest, most resource heavy block full of worst case non-SegWit transactions imaginable? Wow!

!

!!!!!!

Wow!!!!!

Amazing!!!!!!!!!!!!!!

What an incredible endorsement of SegWit's powers!

[Quickseller]

segwit dos not solve quadratics.. it makes it 4x worse:
0.12 4k maxtxsigops (~10sec validation time)
0.14 16k maxtxsigops (~8min validation time)

This is unadulterated jibberish technobabble.

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

The consensus rule for non-segwit signature operations is 20k before segwit and not changed (it can't be increased by segwit as that would be a hardfork), and segwit transactions are much faster to hash (on average and especially in the worst case where they are thousands of times faster).

I am only responding to this habitually dishonest bullshitter because his comments have been quoted in the media.

There is a very good example of Greg Maxwell's rampant dishonesty.

In your comparison, you are comparing an absolute worse case (likely malicious) scenario with the best case scenario of the "solution" that you are pushing.

[anonymoustroll420]

....

In February, Google fully broke SHA-1 using colliding message blocks. https://shattered.io

Colliding message blocks is the same cryptographic attack used by ASICBOOST.

If Satoshi had chosen SHA-1 as a hash function instead of SHA-256, do you think we should patch this cryptographic attack?

The Google attack requires 2^61 operations, while doing a full hash collision with ASICBOOST requires 2^255.48. At what reduced level of security do you think we should do something?

If we don't patch cryptographic attacks, that sends the message that cryptographic attacks on mining are OK. When a more serious attack is found, people will point to this one and say "why was this one allowed". You already think it's an "efficiency gain". If an "efficiency gain" is found that reduces the security to 2^61, that would allow anyone to mine a block with 2^61 operations no matter how high the difficulty, completely breaking mining. In that case, should we not patch it because it's simply an "efficiency gain"?

[jonald_fyookball]

segwit dos not solve quadratics.. it makes it 4x worse:
0.12 4k maxtxsigops (~10sec validation time)
0.14 16k maxtxsigops (~8min validation time)

This is unadulterated jibberish technobabble.

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

The consensus rule for non-segwit signature operations is 20k before segwit and not changed (it can't be increased by segwit as that would be a hardfork), and segwit transactions are much faster to hash (on average and especially in the worst case where they are thousands of times faster).

I am only responding to this habitually dishonest bullshitter because his comments have been quoted in the media.

There is a very good example of Greg Maxwell's rampant dishonesty.

In your comparison, you are comparing an absolute worse case (likely malicious) scenario with the best case scenario of the "solution" that you are pushing.

Well, sort of.

The segwit-transaction containing block doesn't have to be the best case to be better than the worst case QH case.

The dishonest part imo, comes from using his influence as a core developer to enter the middle of a discussion, label one of
his biggest critics' post as  'unadulterated jibberish technobabble' (when it may not be) and then just walk away from the conversation.

[dinofelis]

....

In February, Google fully broke SHA-1 using colliding message blocks. https://shattered.io

Colliding message blocks is the same cryptographic attack used by ASICBOOST.

Gobbledegook.  Asicboost is not an attack.  It is just a smarter organisation of the hash calculations.  In fact, it is so straightforward, that I'm amazed that it took 7 bloody years to discover it, since it is done ALL THE TIME when using, say, AES-256 encryption, and is often part of the design of a symmetric cypher.  That such a triviality took a long time and is considered patentable leaves me speechless.

Here's the simplicity of asicboost explained:

https://bitcointalk.org/index.php?topic=1874983.0

It is not more than the insight that, like all good usage of block cyphers, we do key schedule re-usage.  

[Killerpotleaf]

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

Really? You're telling me that it is possible to construct a block with a single SegWit transaction that might be less resource intensive than the largest, most resource heavy block full of worst case non-SegWit transactions imaginable? Wow!

!

!!!!!!

Wow!!!!!

Amazing!!!!!!!!!!!!!!

What an incredible endorsement of SegWit's powers!

now you're just trolling the poor guy.
he meant that replacing even just 1 TX in a block with a segwit TX will make the block validate faster.
i'm not sure if thats true for a very simple TX, but generally speaking it must be true.


but franky1's statement might not to be " jibberish technobabble "

maybe franky is saying that in most cases replacing typical TX we find in blocks today with a segwit version of that TX will not improve the validation time of that block by very much ( since typically TX are not quadratically heavy )
so segwit provides little Effective incress in validation time while 4x the amount of TX pre-block

segwit dos not solve quadratics.. it makes it 4x worse:

Frankly, IDK if this is what he's getting at there, or if this is at all true, but it feels like we've been franked! this is very interesting...

[Quickseller]

segwit dos not solve quadratics.. it makes it 4x worse:
0.12 4k maxtxsigops (~10sec validation time)
0.14 16k maxtxsigops (~8min validation time)

This is unadulterated jibberish technobabble.

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

The consensus rule for non-segwit signature operations is 20k before segwit and not changed (it can't be increased by segwit as that would be a hardfork), and segwit transactions are much faster to hash (on average and especially in the worst case where they are thousands of times faster).

I am only responding to this habitually dishonest bullshitter because his comments have been quoted in the media.

There is a very good example of Greg Maxwell's rampant dishonesty.

In your comparison, you are comparing an absolute worse case (likely malicious) scenario with the best case scenario of the "solution" that you are pushing.

Well, sort of.

The segwit-transaction containing block doesn't have to be the best case to be better than the worst case QH case.

The dishonest part imo, comes from using his influence as a core developer to enter the middle of a discussion, label one of
his biggest critics' post as  'unadulterated jibberish technobabble' (when it may not be) and then just walk away from the conversation.

His comparison was between a block containing a single SegWit, one input, one output transaction (which would take very little time/resources to validate) and a block that contains a coinbase transaction and one additional transaction with ~0.995 kb worth of inputs (and their associated signatures) and a single output, which would take several minutes to validate based on currently available technology.

Current market conditions make it so that there is no reason for a miner to find a block with a single non-coinbase transaction (except in the case of SPV mining and a subsequent block is found very shortly thereafter another block -- this however is by far the exception, and is not the norm). There are also very few 'business' reasons for a miner to find a block that only contains a single transaction that takes up ~1 MB worth of block space.

[Lauda]

-snip-

ASICBOOST is an exploit per definition of the word exploit in CS. If you claim otherwise, you are either deluded or you're being paid to spread false information. Maybe reddit posts are above your education level: https://www.reddit.com/r/Bitcoin/comments/667js8/asicboost_isnt_an_efficiency_gain

now you're just trolling the poor guy.
he meant that replacing even just 1 TX in a block with a segwit TX will make the block validate faster.
i'm not sure if thats true for a very simple TX, but generally speaking it must be true.

That's what I understood the first time I've read it. I might be wrong, but these trolls were bound to attempt to abuse his statement.

but franky1's statement might not to be " jibberish technobabble "

Yes it is. I've explained it to him a few weeks ago in some other thread, and he just continued to spread the same false information.

[dinofelis]

ASICBOOST is an exploit per definition of the word exploit in CS. If you claim otherwise, you are either deluded or you're being paid to spread false information. Maybe reddit posts are above your education level: https://www.reddit.com/r/Bitcoin/comments/667js8/asicboost_isnt_an_efficiency_gain

But then you can say the same about the standard algorithm that re-uses the first compression result of the first 64 bytes of the header, to ONLY calculate the compression of the second block when it loops over the nonce (the (padded to 64 bytes) 16 remaining bytes, containing the nonce). Why is the re-use of the first compression of this block not an "exploit ; not an efficiency-gain" in the usual algorithm, but is inverting both, that is, keeping the data of the second block constant (and hence re-use the key schedule, as is standard done when, for instance, encrypting a big file with AES-256), considered "an exploit" ?

If you are "honest", aren't you supposed to calculate the ENTIRE HASH of the block header if you change the nonce, and not just the "second part of it, re-using the first piece of calculation" ?  If the re-use of the compression of the first 64 bytes is not an exploit, why is the re-use of the key schedule of the second part then an exploit ?

From what moment onward is re-using the results of an identical calculation, instead of doing it over like an idiot, "an exploit" ?
BTW, as I said elsewhere, this asic boost optimisation is so trivial, and is standard done in most symmetric crypto, that I have a hard time believing that this can successfully be patented and that the patent will hold up in court.

BTW, the idiot that wrote the post on reddit doesn't understand even the level of security provided by PoW.  The level of security provided is not the effort that the "good guy" put into it, but the effort that the "bad guy" NEEDS to spend in order to overcome it.  As such, given that the asic boost optimisation is now public knowledge, that has AUTOMATICALLY dimished the security of the PoW (of all hashcash style PoW everywhere), because an attacker now needs to spend less effort to overcome the security.  As such, NOT USING this gain by the "good guys" (the miners) would be utterly stupid, because it gives a disadvantage to the "good guys" over an improved attack efficiency for the adversary !

This is like thinking that if you do an elliptic curve signature with more effort, the signature is more secure than if you did it with a smarter calculation.  No, the security level is given by the effort needed by the *smartest adversary*, not by the effort you put in YOURSELF.  Duh.

The security level of a 256 bit ECC signature is 128 bits.  Not because YOU use 128 bits or so (you use 256) ; but because the best method publicly known (Pollard's rho attack) can crack it in 2^128 trials and doesn't need to run over 2^256 trials.

As such, the calculation effort needed to prove work has diminished when the Asic boost principle was published in 2016, and as such, lowered all security of all PoW to which this calculation improvement could be applied.

And the standard calculation, of only compressing the first 64 bytes once, and only compressing the second part that changes, already diminished the PoW security.  The invention of ASICS SERIOUSLY diminished the PoW security (because their availability improved the possibilities of an attacker with a given budget to overcome it as compared to when there weren't those ASICS around).

ANY publicly (or privately !) known technique that can render more efficient an attack on a given PoW level, diminishes PoW security in a proportional amount.

(this is BTW, why PoW is a completely ridiculous cryptographic security mechanism).