Pages:
Author

Topic: So who the hell is still supporting BU? - page 5. (Read 29824 times)

legendary
Activity: 4410
Merit: 4766
February 22, 2017, 03:32:48 PM
Lauda your tolerance and persistence is commendable. However your effort is wasted. Selectively ignoring about 4 bitcointalk trolls in this argument will make your life much more enjoyable and any discussions regarding scaling much more useful as it increases the signal to noise ratio to about 100x higher.

sticking head in sand and pretending the dream is a reality will make your life more enjoyable.. but you have to wake up someday. and your dream fades away once the real reality takes over your life.
legendary
Activity: 4410
Merit: 4766
February 22, 2017, 03:30:45 PM
You are diverting attention to what I was taking about. Read your post, and read what I was talking about. I was not talking about throughput, but solely about quadratic hashing.

what your failing to understand is that segwit wont stop anything.
you can pretend it solves things and is 100% utopian fix. but its not

quadratic hashing still will occur after segwit is activated.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
February 22, 2017, 03:26:23 PM
Lauda your tolerance and persistence is commendable. However your effort is wasted. Selectively ignoring about 4 bitcointalk trolls in this argument will make your life much more enjoyable and any discussions regarding scaling much more useful as it increases the signal to noise ratio to about 100x higher.
EDIT: Of course people who respond by taking offence means they know they're trolls themselves, otherwise why would they get offended and think I was talking about them?
legendary
Activity: 2674
Merit: 2965
Terminated.
February 22, 2017, 03:17:20 PM
So what does happen if someone chooses to not use Segwit 'keys' and decides to create extremely expensive transactions? Nothing, they still can't create a TX/block that it significantly (or adequately) bigger in order for the 'attack' to work.
if an attacker makes a 1mb bloated non-segwit tx. then the block is filled. again.. the block is filled and no one else can get their transactions into the block.
doesnt matter what size the block could have been or is.. its filled. end of
You are diverting attention to what I was taking about. Read your post, and read what I was talking about. I was not talking about throughput, but solely about quadratic hashing.
legendary
Activity: 4410
Merit: 4766
February 22, 2017, 02:49:46 PM
So what does happen if someone chooses to not use Segwit 'keys' and decides to create extremely expensive transactions? Nothing, they still can't create a TX/block that it significantly (or adequately) bigger in order for the 'attack' to work.

if an attacker makes a 1mb bloated non-segwit tx. then the block is filled. again.. the block is filled(repeated for emphasis) and no one else can get their transactions into the block.
doesnt matter what size the block could have been or is.. its filled. end of

thus even if you have X thousand users using segwit.. their transactions are still held up in mempools, unconfirmed.

= segwit is not a remedy. its just taking the guns away from the innocent and dumbly thinking that will solve malicious gun crimes. yet malicious gun crimes are still happening because malicious people still have a gun to hold people up.

segwit doesnt magically make the block 2mb.. its all dependant on what type of transactions are in a block that offsets posible expansion of block capacity of that specific block at that specific time.

if all transactions are native block is at 1mb..
if 50% transactions are native that specific block might be 1.5mb
if 0% transactions are native that specifit block might be 2.1mb

but if a spammer fills a block with native transactions.. segwit users cant do crap
legendary
Activity: 2576
Merit: 1087
February 22, 2017, 12:30:23 PM
even activating segwit does not stop worrying about O(n^2) attacks!!
people wanting to cause O(n^2) attacks will still do O(n^2) attacks

wake up to reality.
O(n^2) attacks are only allievated by those using segwit keys.. the thing you need to understand is attackers wont use those keys even after activation. so the problem is not solved.
You are thinking about this completely wrong. Let's revisit:
We know that at 1 MB that quadratic hashing problem is *okay* (to put in this way) and that it opens a DOS attack vector at higher block sizes. I think we can agree on this statement. If people create Segwit TXs, they can create blocks that are bigger than 1 MB. However, in this case the O(n^2) is reduced to O(n) which levitates the problem.
So what does happen if someone chooses to not use Segwit 'keys' and decides to create extremely expensive transactions? Nothing, they still can't create a TX/block that it significantly (or adequately) bigger in order for the 'attack' to work.

Until core does that hard fork to increase 'blocksize'  they said they were going to do Wink
legendary
Activity: 2674
Merit: 2965
Terminated.
February 22, 2017, 12:21:30 PM
even activating segwit does not stop worrying about O(n^2) attacks!!
people wanting to cause O(n^2) attacks will still do O(n^2) attacks

wake up to reality.
O(n^2) attacks are only allievated by those using segwit keys.. the thing you need to understand is attackers wont use those keys even after activation. so the problem is not solved.
You are thinking about this completely wrong. Let's revisit:
We know that at 1 MB that quadratic hashing problem is *okay* (to put in this way) and that it opens a DOS attack vector at higher block sizes. I think we can agree on this statement. If people create Segwit TXs, they can create blocks that are bigger than 1 MB. However, in this case the O(n^2) is reduced to O(n) which levitates the problem.
So what does happen if someone chooses to not use Segwit 'keys' and decides to create extremely expensive transactions? Nothing, they still can't create a TX/block that it significantly (or adequately) bigger in order for the 'attack' to work.
full member
Activity: 322
Merit: 151
They're tactical
February 22, 2017, 11:47:06 AM
If you want to go with an unlimited dragster, at least make in sort it has some kind of brakes, otherwise there can be some accidents :p
newbie
Activity: 26
Merit: 0
February 22, 2017, 07:35:38 AM

BU needs to happen soon, BTC is jammed up again :
88112 Unconfirmed Transactions
https://bitcointalk.org/index.php?topic=1799541.new#new

 Cool
it seems like bitcoin is once again having a spam attack, unlimited is useless here or even harmful, be patient and wait for miners to signal segwit support
legendary
Activity: 4410
Merit: 4766
February 22, 2017, 03:58:40 AM
If you don't want to do that, broadcast your cosmic background spam on a less valuable blockchain.

let me guess your gonna kiss gmaxwells ass like last year and start advertising monero as the replacement for bitcoin.

real funny thing about blockstream scripters
complain that only the chinese are making bitcoins but reprogram the fee estimator to give miners more coin(pools dont care about the fee's. its a bonus, not needed income)

pretend to complain about miner control but only give miners the vote (but fail because miners are more ethical and are willing to wait and see what nodes choose)

pretend to care about the community but only implement code changes for benefit of commercial services(only benefits companies wishing to set themselves up as hubs)

pretend to care about the community. yet stunt real growth of bitcoin and then have the arrogance to say bitcoin cant cope.

legendary
Activity: 1092
Merit: 1000
February 22, 2017, 03:40:41 AM
BU needs to happen soon, BTC is jammed up again :
88112 Unconfirmed Transactions

Bitcoin's market-based priority schema is working fine.

In fact, it's working better than ever because now you can bump up a fee that's too low.

If you don't want to do that, broadcast your cosmic background spam on a less valuable blockchain.

Way ahead of you.  Smiley

Anytime BTC unconfirmed transactions are more 10,000 ,
I use LTC or Eth or Doge until it drops back down.


 Cool
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 22, 2017, 01:40:24 AM
BU needs to happen soon, BTC is jammed up again :
88112 Unconfirmed Transactions

Bitcoin's market-based priority schema is working fine.

In fact, it's working better than ever because now you can bump up a fee that's too low.

If you don't want to do that, broadcast your cosmic background spam on a less valuable blockchain.
legendary
Activity: 1092
Merit: 1000
February 21, 2017, 09:52:24 PM
Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense


You keep missing the point where ~70% of the miners are refusing segwit.  Tongue
Segwit Centralized sha256 is dead in the water. Time to move on.  Wink


Fixed your broken point to make it more reasonable and actionable.  

LOL, the only thing broken is your reasoning skills.  Cheesy

BU needs to happen soon, BTC is jammed up again :
88112 Unconfirmed Transactions
https://bitcointalk.org/index.php?topic=1799541.new#new

 Cool
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 21, 2017, 09:01:26 PM
Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense


You keep missing the point where ~70% of the miners are refusing segwit.  Tongue
Segwit Centralized sha256 is dead in the water. Time to move on.  Wink


Fixed your broken point to make it more reasonable and actionable.  Cool
legendary
Activity: 1092
Merit: 1000
February 21, 2017, 07:57:25 PM
Maybe an indicator of the total estimated processing time for a block could be added in the block headers, and limiting the efffective processing time to this.


or advertising the number of sig op in the block more explicitly from start, and limiting the number of sigop processed to this,as mining nodes are already supposed to know this, if a way can be found not using too much extra bandwidth.

Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense


You keep missing the point where ~70% of the miners are refusing segwit.  Tongue
Segwit is dead in the water. Time to move on.  Wink


 Cool
legendary
Activity: 4410
Merit: 4766
February 21, 2017, 12:19:19 PM
Maybe an indicator of the total estimated processing time for a block could be added in the block headers, and limiting the efffective processing time to this.


or advertising the number of sig op in the block more explicitly from start, and limiting the number of sigop processed to this,as mining nodes are already supposed to know this, if a way can be found not using too much extra bandwidth.

Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense

even activating segwit does not stop worrying about O(n^2) attacks!!
people wanting to cause O(n^2) attacks will still do O(n^2) attacks

wake up to reality.
O(n^2) attacks are only allievated by those using segwit keys.. the thing you need to understand is attackers wont use those keys even after activation. so the problem is not solved.

its like not wanting gun crimes. so you make a law that creates a new voluntary gun shop to open whichs sells plastic guns that fire paintballs.
hoping everyone will buy these guns.
the thing you need to understand is you have not closed the normal gun shops or put rules to force the normal gun shops to close. all segwit has done is effectively say the plastic paintball guns are x% cheaper to use..... thats it
full member
Activity: 322
Merit: 151
They're tactical
February 21, 2017, 12:05:21 PM
Common sense is 20% of bitcoin users :p it's always like this, 20% is still good Smiley

It's why good dev must be like dark vador, pushing what is good for their user on them with an iron hand, otherwise they never understand anything. . It's end less debate, lack of consensus, and it never go anywhere  Sad
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 21, 2017, 11:54:58 AM
Maybe an indicator of the total estimated processing time for a block could be added in the block headers, and limiting the efffective processing time to this.


or advertising the number of sig op in the block more explicitly from start, and limiting the number of sigop processed to this,as mining nodes are already supposed to know this, if a way can be found not using too much extra bandwidth.

Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense
full member
Activity: 322
Merit: 151
They're tactical
February 21, 2017, 11:39:36 AM
Maybe an indicator of the total estimated processing time for a block could be added in the block headers, and limiting the efffective processing time to this. If it's not processed before the indicator,  bye.


or advertising the number of sig op in the block more explicitly from start, and limiting the number of sigop processed to this, if there is more sig op than advertized, bye, as mining nodes are already supposed to know this, if a way can be found not using too much extra bandwidth.
legendary
Activity: 4410
Merit: 4766
February 21, 2017, 11:26:04 AM
Raise the blocksize = automatically spammed with crap and blocks are full again = idiots wanting another blocksize increase. They will never stop crying.

Im up for a conservative 2MB increase AFTER segwit is implemented as recommended by 100% experts. No segwit = no blocksize increase, blame chinkshit miners.

lol oh look someone used cores 2017 script buzzword "conservative" (becoming too obvious now)

seriously the script readers need to spend more time reading code and running bitcoin scenario's rather then script reading "recommended by.."

segwit is not a fix. malicious people wont use segwit keys. they will stick to native keys. segwit solves nothing
the real solution is to let nodes flag what they can cope with and then pools see the node consensus and then the pools make their own pool consensus of what they will produce that the nodes can accept.

as for bloat/spam.
a more effective method is to have a real 'priority' formulae that actually solves the problem.
a more effective method is to have tx sigop limits to solve the issues
a more effective method is to not be kissing dev's asses, and think about CODE solutions
Pages:
Jump to: