Pages:
Author

Topic: BU vs SEGWIT ? - page 2. (Read 2219 times)

hero member
Activity: 770
Merit: 629
March 09, 2017, 01:58:10 PM
#27
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

I'm not even aware of what blockstreamers say.  I just apply logic to the different possible outcomes.

My point is that nothing of all this will ever happen.  Bitcoin will simply stay as it is.  There will not be segwit, nor BU.  
Unless:
1) bitcoin is further centralized, and that centralized entity decides whatever it wants to decide
2) bitcoin loses its first mover edge.  At which point I think non-consensual hard forks will be possible.

But in as much as the consensus mechanism of immutability remains at work, there's no possibility for any of this.

I'm just exploring the logical possibilities of the different actions.

The biggest clusterfuck that can happen, is a backward compatible hard fork that loses miner majority after 6 months.

full member
Activity: 182
Merit: 107
March 09, 2017, 01:55:01 PM
#26
You need to run a separate piece of software on top of Bitcoin to use Lightning. Pretty easy to avoid, just do nothing Smiley

Wait, in another thread you said they were bitcoin transactions, even though they are not in the blockchain.

So now they are "bitcoin transactions" that require additional software on top of bitcoin?
hero member
Activity: 770
Merit: 629
March 09, 2017, 01:52:37 PM
#25
Brrr. The BU sounds like a horrible idea, sort of like a live fork-o-rama with all sorts of different blocks floating around  Shocked

So the best compromise would be a Segwit with slightly larger blocks, the new efficient transactions that consume less space, but without the Lightning thingy

I don't think you can avoid the lightning network once segwit is live.



lol, think harder then, Dino.


You need to run a separate piece of software on top of Bitcoin to use Lightning. Pretty easy to avoid, just do nothing Smiley

I meant: you cannot avoid people to build a lightning network on top of bitcoin, once segwit is alive.  You may try to stay outside of it, that is true.

hv_
legendary
Activity: 2548
Merit: 1055
Clean Code and Scale
March 09, 2017, 01:44:25 PM
#24
Note that the banking industry would love this outcome, as it would be all to easy for their corporate media buddies to claim convincingly that Bitcoin was then a failed experiement

That said, with segwit, bitcoin BECOMES a banking industry...



Explain. Writing ... is not an explanation

That s a very easy one. I try:

Its not supported by AAA banks, nor by bbb banks

but by   C banks - having worst rating ever seen.

 Grin
legendary
Activity: 3430
Merit: 3083
March 09, 2017, 12:28:33 PM
#23
Explain. Writing ... is not an explanation

What will Lightning Network nodes with sufficient transactions (a big network hub) look like, you think ? 



No-one will force you to use the largest channels. They will have their place, for super cheap non-sensitive purchases. But if you want it more private, you'll be able to traverse the Lightning network in the smallest channels. Both ways, and anything in between are possible with Lightning's design

Brrr. The BU sounds like a horrible idea, sort of like a live fork-o-rama with all sorts of different blocks floating around  Shocked

So the best compromise would be a Segwit with slightly larger blocks, the new efficient transactions that consume less space, but without the Lightning thingy

I don't think you can avoid the lightning network once segwit is live.



lol, think harder then, Dino.


You need to run a separate piece of software on top of Bitcoin to use Lightning. Pretty easy to avoid, just do nothing Smiley
legendary
Activity: 4424
Merit: 4794
March 09, 2017, 11:36:09 AM
#22
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
legendary
Activity: 4424
Merit: 4794
March 09, 2017, 11:34:08 AM
#21
to avoid being left unsynced, it needs to ban the opposition so that it doesnt see the oppositions higher blockheight and also doesnt see thier own attempts getting orphaned and doesnt end up trying to grab the highest height just to orphan and remain unsynced.

Again, this is not true.  A "higher block count" doesn't matter if these blocks are not valid.

If the chain contains 5 more blocks of 3 MB, and your node considers only blocks smaller than 1MB, these blocks are simply invalid.  You don't consider them. 
nodes see the highest block height. request the data. and then realise its a rule breaker and orphan it.
nodes see the highest block height. request the data. and then realise its a rule breaker and orphan it.
(endless orphan clusterf*ck where the node never syncs)

You keep the last block of 1 MB as the highest one.  The miners keeping with the old protocol will do the same, and build on this block.  So you will now accept this next block.  And the next 1 MB block.  And the next and still the next.  You are on the old protocol chain.
for a node to get this (lower 1mb block) it needs to sever communication with the chain thats 5blocks higher.. then it only see's the 1mb block as the highest height to then sync to that. without the orphan drama



On the other hand, a BU node will accept these 5 extra blocks as valid.  It will consider the 1MB block next to it as orphaned.  and the next one and the next one.  Because if BU has more hash power, the chain built on the 3 MB blocks which you consider valid is growing with more PoW.  You are on the new butcoin chain.  And there's no confusion.  A BU node will only accept the BU chain (and orphan the old bitcoin branch).  A bitcoin non-BU node will only accept the bitcoin blocks of < 1MB, and consider the other blocks as invalid blocks.  Whether they communicate or not.

your thinking too 2-dimensional. one argument your only considering the rules. next argument your only considering hashrate. next argument you only considering blockheight. next your only considering pools and next your only considering nodes.

your not running multi-dimensional scenarios where all aspects interplay

bitcoin has many dimensions that all enforce each other.(as thats the masterpiece of why bitcoin consensus works) and come to the conclusion of(soft or hard):
not banning= orphans and unsynced(dead) nodes for minority
banning= no orphans and minority nodes synced to a less higher chain because you cant see the opposition, thus able to build a second chain without a fight

But you should seriously distinguish between a soft fork and a hard fork.  

i have many times. its you that over use soft and hard like there are only 2 results
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
hero member
Activity: 770
Merit: 629
March 09, 2017, 11:28:19 AM
#20
ethereum intentionally split by banning opposing nodes (google it: --oppose-dao-fork)

It didn't ban nodes.  That instruction simply installed an ETC client or an ETH client.   With a different protocol.  It is as if you could use a bitcoin core client, and give the instruction --run-litecoin.

And transactions from one chain WERE transmitted to the other chain, which caused a lot of surprise.  But this is normal: miners wanted the fees, so they went LOOKING AFTER valid transactions (not on the network, but on the block chain !).

lol bitcoin and litecoin are different coins. etc and eth are different coins. they have their own networks.
they have their own mempools.
they do not intercommunicate. because they only connect to the side they like and ban from talking to the side they dont like. to avoid the orphan drama.

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.
There is no NEED to communicate, but it is not the fact of stopping the communication that makes that there are two chains of course.  The double-valid transactions WILL get across (miners will pick them from the other chain) and the block information is not relevant because mutually invalid.

butcoin and bitcoin will also be entirely different coins, like ETC and ETH.  And yes, most probably their clients will end up only talking to one another within their network, but it is not this "banning" that splits the chain.
hero member
Activity: 770
Merit: 629
March 09, 2017, 11:24:52 AM
#19
Brrr. The BU sounds like a horrible idea, sort of like a live fork-o-rama with all sorts of different blocks floating around  Shocked

So the best compromise would be a Segwit with slightly larger blocks, the new efficient transactions that consume less space, but without the Lightning thingy

I don't think you can avoid the lightning network once segwit is live.
legendary
Activity: 1372
Merit: 1014
March 09, 2017, 11:21:36 AM
#18
Brrr. The BU sounds like a horrible idea, sort of like a live fork-o-rama with all sorts of different blocks floating around  Shocked

So the best compromise would be a Segwit with slightly larger blocks, the new efficient transactions that consume less space, but without the Lightning thingy

Why is no one doing that? Ideology war?  Roll Eyes
legendary
Activity: 4424
Merit: 4794
March 09, 2017, 11:17:31 AM
#17
ethereum intentionally split by banning opposing nodes (google it: --oppose-dao-fork)

It didn't ban nodes.  That instruction simply installed an ETC client or an ETH client.   With a different protocol.  It is as if you could use a bitcoin core client, and give the instruction --run-litecoin.

And transactions from one chain WERE transmitted to the other chain, which caused a lot of surprise.  But this is normal: miners wanted the fees, so they went LOOKING AFTER valid transactions (not on the network, but on the block chain !).

lol bitcoin and litecoin are different coins. etc and eth are different coins. they have their own networks.
they have their own mempools.
they do not intercommunicate. because they only connect to the side they like and ban from talking to the side they dont like. to avoid the orphan drama.

yes i agree initially it was a consensus/controversial event. but then turned into a bilateral split. by nsuring they avoided the orphan drama by avoiding inter-communication
hero member
Activity: 770
Merit: 629
March 09, 2017, 11:15:27 AM
#16
to avoid being left unsynced, it needs to ban the opposition so that it doesnt see the oppositions higher blockheight and also doesnt see thier own attempts getting orphaned and doesnt end up trying to grab the highest height just to orphan and remain unsynced.

Again, this is not true.  A "higher block count" doesn't matter if these blocks are not valid.

If the chain contains 5 more blocks of 3 MB, and your node considers only blocks smaller than 1MB, these blocks are simply invalid.  You don't consider them.  You keep the last block of 1 MB as the highest one.  The miners keeping with the old protocol will do the same, and build on this block.  So you will now accept this next block.  And the next 1 MB block.  And the next and still the next.  You are on the old protocol chain.

On the other hand, a BU node will accept these 5 extra blocks as valid.  It will consider the 1MB block next to it as orphaned.  and the next one and the next one.  Because if BU has more hash power, the chain built on the 3 MB blocks which you consider valid is growing with more PoW.  You are on the new butcoin chain.  And there's no confusion.  A BU node will only accept the BU chain (and orphan the old bitcoin branch).  A bitcoin non-BU node will only accept the bitcoin blocks of < 1MB, and consider the other blocks as invalid blocks.  Whether they communicate or not.

But you should seriously distinguish between a soft fork and a hard fork. 

hero member
Activity: 770
Merit: 629
March 09, 2017, 11:06:22 AM
#15
ethereum intentionally split by banning opposing nodes (google it: --oppose-dao-fork)

It didn't ban nodes.  That instruction simply installed an ETC client or an ETH client.   With a different protocol.  It is as if you could use a bitcoin core client, and give the instruction --run-litecoin.

And transactions from one chain WERE transmitted to the other chain, which caused a lot of surprise.  But this is normal: miners wanted the fees, so they went LOOKING AFTER valid transactions (not on the network, but on the block chain !).
legendary
Activity: 4424
Merit: 4794
March 09, 2017, 11:02:09 AM
#14
Nevertheless, there are several solutions proposed to this problem.  One is simply to increase the block size again.  BU.  However, in order to do so, one needs a HARD FORK.  New blocks (bigger than 1 MB) will not be accepted by old protocol.  As such, chances are that two different coins emerge: a "big block BU bitcoin", and a standard bitcoin.  Like ethereum split in ETC and ETH.  

no

ethereum intentionally split by banning opposing nodes (google it: --oppose-dao-fork)
hence why you can spend coins on eth but keep coins on etc because they do not inter-communicate to add the coin to the mempools of both sides

this is different than a consensus where only one chain survives and the opposition simply cannot sync because it has different rules and simply ends up orphaning everything it see's

to avoid being left unsynced, it needs to ban the opposition so that it doesnt see the oppositions higher blockheight and also doesnt see thier own attempts getting orphaned and doesnt end up trying to grab the highest height just to orphan and remain unsynced.



when it comes to which to choose and what happens next is dependant on what the oppositions do.
for instance without there being a banning event.

its either consensus (high acceptability rate by the network) where by the high acceptability will see low orphan rate because they win the height more often and where the minority orphan out ALOT but ultimately one chain. and the minority just dead and unsynced because although they see the highest blockheight they will orphan it because the data wont meet their rules.

or controversial(above medium acceptability rate) where by the above medium acceptability will see more orphans rate because they win the height but have orphans happening often as there is a bit more of a fight for height.. but ultimately one chain. and the minority just dead and unsynced


whether its soft (change occurs only by pools trigger) or hard (change occurs by NODES and pools trigger)
consensus, controversial .. or worse intentional split(banning AKA bilateral split) can happen.

yes even going soft, core(managed by blockstream) can (and admittedly will) split the network
BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% (C) under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain(B)
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.(A)
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
What you are describing is what I and others call a bilateral hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral ... Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

hero member
Activity: 770
Merit: 629
March 09, 2017, 10:26:54 AM
#13
Explain. Writing ... is not an explanation

What will Lightning Network nodes with sufficient transactions (a big network hub) look like, you think ?  
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
March 09, 2017, 10:17:57 AM
#12
So why block can`t have 32 MB like Satoshi did ?

Theoretically, it could.  Problem is we can't seem to all agree.
legendary
Activity: 3430
Merit: 3083
March 09, 2017, 10:12:24 AM
#11
So why block can`t have 32 MB like Satoshi did ?

Why not get it correct instead


Satoshi's original client had NO blocksize limit at all, the 32MB limit was on network messages, not blocks


Then, who introduced the 1MB limit? It was Satoshi
hero member
Activity: 656
Merit: 501
XBY - New Tech Coin (POSIGN) xtrabytes.global
March 09, 2017, 10:08:08 AM
#10
So why block can`t have 32 MB like Satoshi did ?
legendary
Activity: 3430
Merit: 3083
March 09, 2017, 09:48:31 AM
#9
Note that the banking industry would love this outcome, as it would be all to easy for their corporate media buddies to claim convincingly that Bitcoin was then a failed experiement

That said, with segwit, bitcoin BECOMES a banking industry...



Explain. Writing ... is not an explanation
hero member
Activity: 770
Merit: 629
March 09, 2017, 09:46:27 AM
#8
Note that the banking industry would love this outcome, as it would be all to easy for their corporate media buddies to claim convincingly that Bitcoin was then a failed experiement

That said, with segwit, bitcoin BECOMES a banking industry...
Pages:
Jump to: