Bitcoin Forum
January 27, 2020, 07:15:05 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 874 »
5821  Bitcoin / Bitcoin Discussion / Re: How the chinese BUcoin takeover will be destroyed on: March 10, 2017, 12:05:17 AM
I'm not getting it, where is this "BTU"

its scripts
other script words to watch for contain
"conservative"
"ad-hom"
"BUCoin"

many people repeating the same thing=brainwashing
https://www.youtube.com/watch?v=eZVv2AOCnaA

you start to spot the obvious script readers
and the funny scripts from blockstreamer
"BU causing a fork will damage bitcoin" .... later, same people.... "BU should fork off"

its like they dont even understand what they are saying it. and just saying it for some competition or some prize

which are the only reason bitcoin continues being as solid as ever

really?
OMG
i know you love gmaxwell.. just buy him a wedding ring already.

P.S
if you think bitcoin cannot survive without gmaxwell.. then you have no clue what bitcoin really is

devs can come and go...
if you think bitcoin should be controlled by only a couple devs and 100 spell checkers... then its you admitting you want centralisation and human control.
go play with fiat and kiss IMF ceo's ass
5822  Bitcoin / Bitcoin Discussion / Re: How the chinese BUcoin takeover will be destroyed on: March 09, 2017, 11:59:59 PM
PS: Bitcoin does NOT scale to mainstream levels on-chain, overnight
FTFY

but taking rational user adoption over natural time period of years/decades.

but then squashing it into a fake rhetoric of what users will do overnight. to over sell the need for commercialised hubs... is the OP's failure and the failure of the script writer the OP follows.

stopping natural progressive growth over time, using "gigabytes by midnight" and "visa capacity by 11pm" are stupid and illogical reasons to proclaim as justifications to halt onchain growth.

whats next amputate your kids before they are 6 months old due to fear of statistics that your offspring may run into a car sometime befor he is 40. thus no legs=no running=problem solved?

whats next go back in time to 1996 and tell activision to not ever progress on making Call of Duty games in the future because 1996 tech cant handle the need for a 1mb internet and 60gb hard drives because 1996 only has dialup and 4gb hard drives...
5823  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 09, 2017, 11:50:11 PM
also worth noting

miners dont care about blocksize.

an ASIC holds no hard drive. an asic receives a sha256 hash and a target.
all an asic sends out is a second sha256 hash that meets a certain criteria of X number of 0's at the start

miners dont care if its 0.001mb or 8gb block..
block data still ends up as a sha hash

and a sha hash is all a miner cares about



pools (the managers and propagators of blockdata and hash. do care what goes into a block)

when talking about blockdata aim your 'miner' argument to concern pools ... not the miner(asic)
5824  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 11:16:28 PM
My favorite scenario is where bitcoin successively hard forks into several different coins.  

you can do that now. find a few people that agree with you. and then set your node to blacklist everyone apart from those people.
thus starting your own network that wont orphan against bitcoin because it doesnt see bitcoin.

you dont need any big community activation event. just find people that want the same as you and connect to them and ban the rest.

you then have your own altcoin
5825  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 09, 2017, 10:30:48 PM
From memory the closest we've come to that to date was that single transaction 1MB block from f2pool that took nodes up to 25 seconds to validate. It is possible to make it much worse, but newer versions of bitcoind (and probably faster node CPUs) would have brought that down. Rusty at the time estimated it could still take up to 11 seconds with 1MB:

https://rusty.ozlabs.org/?p=522

So yeah it has been used... possibly unwittingly at the time.

by limiting blocks ability to make a 1mb tx
by having improvements of libsec
by having hardware improvements (raspberry Pi is now atleast v3) quadratics doesnt become an issue.

if blocks grow to say 8mb we just keep tx sigops BELOW 16,000 (we dont increase tx sigop limits when block limits rise).. thus no problem.

however needing to rely on "probability of time" or "hope of 100% user migration of funds to segwit keypairs" is not a good enough solution to me and not a good enough thing to be selling segwit as the solution for. (because 100% key adoption wont occur, malicious users will stay with native keys on purpose)
5826  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 09, 2017, 10:12:47 PM
Your sarcasm escaped me. Though I must admit your statement elicited some surprise, as you have indeed been otherwise consistent in your advancing the notion that the quadratic hashing time solution within The SegWit Omnibus Changeset could simply be stepped around by an attacker.

Why I am trying to tell you is that it doesn't matter. It's not a problem in any systemic sense. Market forces will conspire to orphan blocks that take an inordinate amount of time to verify. Regardless of which -- or even if any -- scaling solution be adopted.

so there has never been an excessively quadratic blocks in bitcoin.. due to faith in "time"

Cheesy are you sure Cheesy

careful how you reply, careful what you say next. the blockchain history never lies
5827  Bitcoin / Bitcoin Discussion / Re: What happens if BU fails VS What happens if SegWit fails on: March 09, 2017, 10:03:39 PM
Of course, because the A chain is NOT ANY LONGER.  So A "being stuck at 460001" is perfectly normal,
your getting it

it is the longest chain that is in agreement with A's protocol.
and now you lost yourself again.
A is not the longest chain.. u just said it yourself its not.. just one sentance prior.
the only way for 460001a to be the longest chain.. is to not see any peers with 460003b.. which involves .... BANNING B nodes

Quote from: franky1
but the B nodes keep growing.
no way would B drop 460003 to go back to 460001
if B accept and happy with 460002B1 460003b2
Of course.
Quote from: franky1
A stuck at 460001
Because that was the longest A chain up to that point.

only if A has banned B

But now, an A-miner has released a second A block, built upon 460001 (because that miner, too, has an A node that has as a longest chain, the one with 460001, and has mined a block on top of it).
only if A has banned B
other wise A sees 460002A and 460003B and still sees 460003B as the highest height and keeps requesting what B has as they have the heighest height.
again resulting in orphans and being stuck even if 460002a exists.
still requesting 460003 because it can see 460003

That A-miner now broadcasts his block 460002A2.  This is relayed by all A-type nodes.  When your "stuck" A-type node receives this block, he accepts it, and is now at 460002A2, *like he should* because that's now the longest A-compatible chain.

unless banning B... 460002A2 is not the longest chain.

i think i am getting where your missing something.
a node doesnt know the contents of a block until it receives it and checks it.

your thinking A sees that 640003 is bad before even downloading it.
sorry but it has to download it to see what it is.

meaning every time it scans the network all it sees is 640003 is highest.
without knowing if its a 640003a or a 640003b unless it requests it to see what it is..

again to avoid getting 640003b it has to ban nodes holding 640003b

Quote from: franky1
A then has to decide to:
continue in orphan hell of rejecting B
stay stalled by just turn node off
upgrade and join B
or ban B to not see 460003 and instead able to build on A
Well, of course, he will do the last thing, and take block 460002A2 when it becomes available.  Nothing difficult.
That the A-node, with its longest chain up to 460001A1
A is only longest if A is all it sees... by banning B nodes

was "wasting its time checking B blocks" is not a problem, it HAD the longest possible chain for him at that point.  When it receives the next A block, it adds it.  As it should.

No "orphan drama".  
A nodes build the A chain.  BU nodes build the B chain.

when it bans B nodes
5828  Bitcoin / Bitcoin Discussion / Re: What happens if BU fails VS What happens if SegWit fails on: March 09, 2017, 09:21:57 PM
But of course not.  For the old nodes, B1 and B2 are simply invalid blocks.  So their height is at 460001.  If I send an invalid block to another node, I suppose he's simply going to reject it, no ?  

LOL
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it

thus not syncing and A being stuck at 46000A1..
but the B nodes keep growing.

no way would B drop 460003 to go back to 460001
if B accept and happy with 460002B1 460003b2 they continue with it
A stuck at 460001

A then has to decide to:
continue in orphan hell of rejecting B
stay stalled by just turn node off
upgrade and join B
or ban B to not see 460003 and instead able to build on A

Otherwise, I can bring down the whole bitcoin network by making 5000 successive bogus invalid blocks with erroneous hashes (not difficult) and tell the whole bitcoin network that we are 5000 blocks ahead ?   Everything comes to a grinding halt with such a simple attack ?

now your just making up fairy tales. because they would just not be accepted either.. nothing to do with height. but about not meeting rules.

Of course not.  B1 and B2 are simply considered invalid blocks by old nodes.  
invalid to A which leaves A stuck (B accepts them so B continues)

The old nodes will all agree that they are at height 460001.

no old nodes will see its peers are at 460003. and keep trying to get it to sync to it. but then reject what it gets to be left at 460001a
leading to sync issues.
forcing the user to decide.
join B(upgrading software)
be a numbskull just remaining unsynced requesting and rejecting
ban B to grow A because if A grew A without a ban if A made 460002.. the nodes will still be looking to grab 460003B and rejecting 460002A

And those nodes receiving blocks B1 and B2 will reject them, and not even propagate them.  But all BU nodes will accept them, propagate them, and their counter will be at 460003.
now your getting it
An old node asking a BU node to send him the blocks, will conclude that this node is "confused".  Otherwise, I can bring down the whole bitcoin network with one single "confused" node 5000 fake blocks in the future.
Period.
now your getting it.

leading to sync issues for A.
forcing the user to decide.
join B(upgrading software)
be a numbskull just remaining unsynced requesting and rejecting
ban B to grow A
5829  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 09:10:33 PM
You should really stop telling this.   With a hard fork, there is no "orphan risk",  you just have two chains, two coins, and that's it.

lol you really have been fed the spoon of blockstream

"hard fork" is an umbrella term with several possible outcomes below it.

its whoevers script you have read that has sold you into thinking that soft = 1 result best case scenario. and then stroked ur head into thinking only good things will happen

hard=1 result worse case scenario. and punched ur heead into thinking only bad things will happen

please try understanding bitcoin and run MANY scenarios.
it will help you understand bitcoin better
5830  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 09, 2017, 09:07:31 PM
Quote
meaning segwit doesnt need 100% of users to move their funds to segwit keys (weeks after activation) just to possibly get a segwit fix to fix it(never gonna happen anyway), because belief alone in 'time' has protected the network thus far and will continue to

Yes - now you're getting it.

my "doesnt need" was sarcasm because segwit does actually need it.
the sarcasm was pointed at those that think segwit will fix the issues simply by the belief in 'time'
5831  Bitcoin / Bitcoin Discussion / Re: BU vs SEGWIT ? on: March 09, 2017, 08:34:34 PM
The consensus protocol is supposed to "keep status quo" on all economically relevant parameters.  If this mechanism is sufficiently strong, it will simply be *impossible* to modify the block size.  And that's not the fault of Joe or Jack.  It is bitcoin's consensus dynamics.

until blockstream decided to avoid consensus by going soft(pool only) and then having extra bits added to bilaterally split to avoid node consensus at activation. if pools stupidly people allow it (26% are all for it as of today)

and then blockstream having their nodes centred nearest the pools as the upstream filters (FIBRE) to filter preferential data downstream...
thus making them the spoon feeders because everything has to feed through them first due to everything else baned out as being an upstream and only accepted as a 'compatible' downstream.

segwit wont achieve the quadratic/malleability fixes..(fix is not about activation but disarming voluntary segwit keypair users(malicious people will avoid moving funds to those keys, thus quadratic/malleability will still occur using native keys))
segwit wont achieve the expectant tx count boost..(fix is not about activation but disarming voluntary segwit keypair users(malicious people will avoid moving funds to those, thus maximum expectant boost wont be achieved due to those remaining using native keys))

segwits secret(now public) goal is to grab the network and everyone running their software and needing their rules. leaving anyone else off the chain.
5832  Bitcoin / Bitcoin Discussion / Re: BU vs SEGWIT ? on: March 09, 2017, 08:19:24 PM
The biggest clusterfuck that can happen, is a backward compatible hard fork that loses miner majority after 6 months.

retaining majority for 6 months leads to many more than 6 months for the minority to try over taking. because they are many blockheights ahead.
losing advantage/chance as time goes on

for the last 8 years people have debated the whole 51% attack vector that can undo months/years worth of work.
but that those fears are dismissed when you actually calculate what is required for a minority to overtake to then gain blockheight(and chainwork).

if 51% A - 49% B
in the first block
460,000X0 - (event trigger)
then
hashrate vs hashrate B 'could' get height become majority
but chances are A get the next block

460,000X0 - 460,001A1
B then see 460,001 and reject it.
B then see 460,001 and reject it.
blah blah blah. they cant sync

at worse B ban communication to A for B to build their own chain(altcoin)(lets imagine B they reconfigure their node in 10 minutes (quick recode and banning) meaning A gets ahead in that setup period that B is wasting
A: 460,000X0 - 460,001A1 - 460,002A2
B: 460,000X0
by which time B are then a block or 2 behind.
B then start mining and making a block, but ofcourse A is also making blocks too
460,000X0 - 460,001A1 - 460,002A2 - 460,002A3
460,000X0 - 460,001B1

over an average of a day(144 blocks) with a 2% differential. A could gain ~3 blockheight
460,144A - 460,144A
460,141B - 460,141B

over an average of a week(1008 blocks) with a 2% differential. A could gain ~50 blockheight
461,007A - 461,008A
460,957B - 460,958B

so now B chances of overtaking are slimmer.

over an average of 2 weeks(2016 blocks) with a 2% differential. A could gain ~100 blockheight
462,015A - 462016A
461,915B - 461,916B

B have not created 2016 blocks in 2 weeks. so their difficulty drops(meaning they can make blocks with less chainwork)
you may think this makes B have the advantage because now they can make blocks faster. but... here is the clincher

if B accelerated by having a few % lower chainwork needed advantage due to lower difficulty. they are still 100 blocks behind. so aswell as building blocks they have to make up for the loss. meaning
if A just made 2016 blocks in the next 2 weeks. B has to make 2116 just to get even.

and here is the punch line.
chainwork.
if it got to a point of
464,031A - 464,032A
464,031B - 464,032B

464,032B's chainwork will be lower than 464,032A chainwork.
imagine each block cost 100 chainworks per block to solve
over the 4 weeks A has a chainwork of 403200 for block 464034A
over the 4 weeks B has a chainwork of 389088 for block 464034B

meaning if B joined the network to attempt an over throw, it gets orphaned anyway, not due to blocksize, not due to hashpower, not due to blockheight, but due to chainwork.
5833  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 06:43:05 PM
carlton wants BU to altcoin.. he even calls it an altcoin..
carlton pretends to cry fears of an altcoin
carlton wants BU to altcoin.. he even calls it an altcoin..
carlton pretends to cry fears of an altcoin
carlton wants BU to altcoin.. he even calls it an altcoin..
carlton pretends to cry fears of an altcoin
(his pretense changes by the hour)

yet its blockstream that will trigger the altcoin.. and thats carltons real fear.. blockstream having to trigger because they are an altcoin or fear the community where blockstream is being left as the minority. and not owning and controlling the network.

they hate anything not blockstream
all of the implementations that are not blockstream have been attacked.
rather than seeing them as part of consensus and the diverse decentralised nature of bitcoin

carlton doesnt care about bitcoins consensus or diverse decentralisation of multiple implementations. he just wants his king to control it all
5834  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 06:29:12 PM
It's not just 75% - the first phase is 75% for a full difficulty adjustment period.

When they stay at 75% for a full difficulty adjustment period then they will start broadcasting willingness to mine a bigger block.

When enough have signalled intent to accept bigger blocks for a full adjustment period WITHOUT dropping below 75% then they will start mining bigger blocks.

That's what I have seen them posting, so it will take maintaining 75% consensus for several difficult adjustment periods BEFORE the first bigger blog.
whereby the extra time gives extra oppertunity to get even better than 75% to reduce orphan risks and reduce the nodes left unsynced, by letting the 25% decide to upgrade or be left behind


The only thing that could throw a wrench in that is UASF
which is a fake buzz word for a HBS (Hard because its node and pool enabled. Bilateral Split because its about banning opposition.
which blockstream are stroking the sheep to sleep pretending its "soft"(the S of UASF) but its not soft at all. its just bait and switching with acronyms of fake meaning (node and pool enabled = hard)

in which case they may need to emergency hard fork earlier.

FTFY

clarity

soft and hard is simply
soft: pool only vote
hard: nodes and pools vote

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split (UASF)- intentionally ignoring/banning opposing rules and not including them. result: 2 chains

if blockstream want to ban anything thats not blockstream then they can play on their 26% hashpower(today stats) all they like. and pretend its achieved 100% by just ignoring the other 74% of the network.. they are still going to be on a minority and less height altcoin chain.
5835  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 06:05:32 PM
carlton doesnt understand consensus and orphans (the main security mechanism built into bitcoin and what BU USES)
strangely he doesnt realise its his kings wishes to avoid consensus and where blockstream have added code to ban opposition.
where as BU has not.

end result.
if BU triggers. one network with orphan risk for the minority, leaving minority unsynced(BU will not do any banning to cause a split)
if segwit triggers. 2 chains, because segwit will ban pool(nodes) and their blocks that try to build old blocks ontop of segwit, (to avoid segwit getting orphaned)

but yes if BU triggers.. the minority 'could' LATER split. by the minority CAUSING a split because the minority want to keep away from BU rather than accept consensus and switch to the majority(BU).

in short
BU wont CAUSE a split by banning minority.. but the minority to BU can cause a split by refusing to join the majority and refusing to just give up

though BU could trigger at low majority. they wont actually do it. they would wait a bit longer and do whats safe and not risking the rewards due to orphans.

BU relies on consensus..
segwit relies on bypassing consensus(first going soft to avoid node consensus, then banning opposition to avoid orphan risk)

5836  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 05:56:44 PM
though any majority will lead to gaining the blockheight. the FIGHT(orphan risk) for blockheight is much more if the majority was say 51% rather than say 91%

the higher the % the less orphan risk and the better chance of a stable chain thats not orphaning all the time.

some deem 95% too high because its tough to get random people to near unanimously agree on anything
some deem 51% too low because its just increasing the orphan arguments (much like the scottish and EU referendums of slight majority, still arguing and wanting another referendum)

hence a middle ground of say 75% reduces orphan risks and arguments but more of an attainable agreement by a safer majority than say 51%

thanks for the explanation franky, i can understand the orphan risk and the relationship with the percentages when put it like that.

but what about risk of splitting the network into two chains.
this is what my question basically is, i don't know how right or off the mark i am though.
i say with 95% the remaining 5% can not really stay around for long and they either die or switch.
but with 75% the remaining 25% seems too big and can stick around and continue producing blocks

no
the 5% minority see the blockheight (bu being higher) request the blockheight. see its a rule breaker to the 5%. reject it
and again
the 5% minority see the blockheight (bu being higher) request the blockheight. see its a rule breaker to the 5%. reject it
and again
(which as you say is 5% not syncing and either die(stuck) or change to the majority to rejoin)


the 25% minority see the blockheight (bu being higher) request the blockheight. see its a rule breaker to the 25%. reject it
and again
the 25% minority see the blockheight (bu being higher) request the blockheight. see its a rule breaker to the 25%. reject it
and again
(which as you say is 25% not syncing and either die(stuck) or change to the majority to rejoin)
meaning in short MORE nodes having the headache. but in both cases no second chain(just 1 chain and some dead nodes(the less the % the less dead nodes)

for the 5% or 25% to build on a LOWER height. they have to ignore (ban) dis-commnicate / split from the majority. to then only see the minority as the highest height. to then sync to that without the orphan game of unsyncing them.

this is called a bilateral split (intentional ban).
consensus mechanism (orphaning) exist for a good reason. to keep one chain that the majority can agree on.
to make a second chain exist and survive without orphans requires avoiding the majority by banning from it, to not see the majority blockheight, to then not fight it

even ethereum done this by their '--oppose-dao-fork' to know which nores to white list and which nodes to blacklist to avoid orphan drama and only see the blockheigh of the chain they prefer
5837  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 09, 2017, 05:37:35 PM
Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens Roll Eyes)
who the damned F*ck should be allowed to build a single tx that uses 20% of a block!!
who the damned F*ck should be allowed to build a single tx has 16,000 sigops!!

Bitcoin is permissionless. The proper answer to "who the damned F*ck should be allowed to build..." is anyone who wishes to.

But another aspect of permissionless is the fact that no miner is compelled to include that transaction into a block. In fact, there is a natural disincentive to any miner including such a transaction into a block. Blocks that take a long time to validate are likely to be orphaned by other blocks which validate quickly.

but this is where the rules need to be defined. so that if a malicious pool did add it. the LOWER tx sigops would be knowingly rejected by consensus so pools wont bother.

by keeping it at 16,000 malicious pools 'could' accept it and know its a valid block and only have to worry about 'timing' as the disincentive, rather than RULES.

however if you prefer not to have RULES and just rely on belief or faith of pools.. then that is a weakness.
however if belief and faith were strong for such an occurrence not to happen. than quadratics has never been a problem and never be a problem because bitcoin is protected by belief that it will get orphaned due to 'time'.

meaning segwit doesnt need 100% of users to move their funds to segwit keys (weeks after activation) just to possibly get a segwit fix to fix it(never gonna happen anyway), because belief alone in 'time' has protected the network thus far and will continue to
5838  Bitcoin / Bitcoin Discussion / Re: Why is BU consensus at 75% and isn't it bad on: March 09, 2017, 05:30:49 PM
though any majority will lead to gaining the blockheight. the FIGHT(orphan risk) for blockheight is much more if the majority was say 51% rather than say 91%

the higher the % the less orphan risk and the better chance of a stable chain thats not orphaning all the time.

some deem 95% too high because its tough to get random people to near unanimously agree on anything
some deem 51% too low because its just increasing the orphan arguments (much like the scottish and EU referendums of slight majority, still arguing and wanting another referendum)

hence a middle ground of say 75% reduces orphan risks and arguments but more of an attainable agreement by a safer majority than say 51%
5839  Bitcoin / Bitcoin Discussion / Re: What happens if BU fails VS What happens if SegWit fails on: March 09, 2017, 04:57:25 PM
He is most certainly confused and has a flawed understanding of Bitcoin. I can't seem to recall something in my thought process so I thought I'd ask. We know that blocks bigger than 1 MB from chain B would surely get orphaned on chain A. However, what about blocks from chain A being relayed to chain B (considering this would be a 'unilateral split')? I don't see why 1 MB blocks from chain A would get orphaned on chain B under current conditions. Care to elaborate?

This is where an unilateral split gets tricky, and why BU needs majority hash rate.

Let us say that block A1 is the last common block ( A's are less than 1MB).  BU pulls the trigger at that moment.  What does that mean ?  They mine at least ONE B block, bigger than 1 MB: B1.

We now have: for BU nodes: A1 - B1
However, for old nodes: only A1 (B1 is invalid).

BU has more hash rate.  It now builds a B2.
For BU nodes: A1 - B1 - B2
for old nodes: A1 (both other blocks are invalid).

Now, a "minority miner" mines A2, built on top of A1 (B1 and B2 are invalid blocks for him).

this is where your 2-dimensional thinking falls apart.
at this point . without A banning communication with the network
lets use blockheight numbers

For BU nodes: 460,001A1 - 460,002B1 - 460,003B2
for old nodes: 460,001A1 - 460,002A2

ALL nodes will still see 460003 and ask to get it to sync to highest height.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
(endless orphan drama for minority and not syncing)

to get the old nodes to see 460,002A2 to sync.. they have to avoid seeing 460,003B2 by banning communication.or to get the majority(hashpower to get height) by pushing passed 460,003B2 so that there was a 460,001A1 - 460,002A2 - 460,003A3 - 460,004A4

in which case
ALL nodes  see
460,001A1 - 460,002A2 - 460,003A3 - 460,004A4 as the height
and BU orphan their  - 460,002B1 - 460,003B2 and go with
460,001A1 - 460,002A2 - 460,003A3 - 460,004A4 as the height

because A rules are acceptable to BU.

now.. this is the thing your also forgetting.
although BU 'could' trigger at low majority. POOLS wont trigger with low majority because they know the orphan risk of their own blocks is increased. so they wont trigger unless they know the risk of losing their block reward was little to non.

meaning it will take alot of effort of the minority to try to overtake the majority because the majority would be significantly higher


this is why as of today and for the last 2 years of being on the network, BU has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk

this is why as of today and for the last 2 years of being on the network, XT has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk

this is why as of today and for the last 2 years of being on the network, classic has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk

they want high consensus and will only trigger with high safe consensus

which blockstream is scared of. and has been crying, pleading, fudding, fake doomsdaying, bait and switching, playing victim card of.
while secretly(now public) knowing its only blockstream that will bilaterally split to keep their segwit rules alive (as an alt) rather than just giving up and saying the community just doesnt want it.(if consensus is not reached). or creating the altcoin if consensus is reached to ensure their chain is not overtaken
5840  Bitcoin / Bitcoin Discussion / Re: BU vs SEGWIT ? on: March 09, 2017, 04:36:09 PM
There is no orphan drama when there is a hard fork.  Blocks on one chain are simply invalid on the other one, and respective miners build on one or the other.

you have been mis sold the fake dooms day speech by blockstreamers
hard and soft are umbrella terms.. below these umbrella terms are sub categories of what can happen

clarity

soft and hard is simply
soft: pool only vote
hard: nodes and pools vote

softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

even in a soft (pool only) event can lead to a bilateral split
even in a hard (node and pool) event can lead to a consensual one chain agreement,

you have been mis sold by blockstreamers only mentioning best case scenario of soft and worse case scenario of hard. and false promoted it as being the only 2 conclusions
Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 874 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!