BU vs SEGWIT ?

[franky1]

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

[1713883947]

1713883947

[1713883947]

1713883947

[1713883947]

1713883947

[1713883947]

1713883947

[franky1]

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

[Carlton Banks]

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  

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

[hv_]

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.

 

[dinofelis]

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

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

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.

[AliceWonderMiscreations]

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

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?

[dinofelis]

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.

[dinofelis]

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.

 

Indeed, how does a mere mortal use the lightning network ?   I try to imagine how this works.  Suppose I'm a mere mortal, using bitcoin, say, 10 times a year to buy something on the internet, and to sell something else on the internet.  And Joe, my neighbour, too.  And Jack, my other neighbour, too.  Each of us, we have, say, 5 bitcoin or so.  And we buy and sell 10 things a year with bitcoin.  Like 100 million other mortals.  Suppose that one of these things is, I want to buy a second hand i-phone from a guy in New Zealand (not a professional salesman, just a guy selling his old phone).  
In the old days, he would send me his bitcoin address, I would send him 0.1 bitcoin, and he sends me the phone.  I could use escow eventually.  That's it.  But now, I don't see how "setting up a lightning channel for just 0.1 bitcoin" to a local node, is going to help.  If I do so, at the end, we settle, with a transaction on the chain.  So this takes one on-chain transaction on my part, and another one on the New Zealand side if we set up, and close our connections for this single transaction.

So the only way in which this is beneficial, is that I open a lightning channel to a local node with all the coins I will probably need this year, for my 10 transactions.  But in order for that channel to *last that long*, I need *a reliable node* that will stay open that long, and has sufficient other connections that my payment can reach my destination.   The only way for that to be viable, is that my neighbours, Joe and Jack and so on, also use one of these central hubs, that will reliably transmit stuff across the network ; has enough "escrow coins" to open all these channels, and has enough profit to be a reliable node.

In what way is that "other node" different from a local bank that keeps my coins, knows my transactions, and so on ?  Yes, I keep control.  Yes, I can terminate at any moment.  But the service will have to be paid for.  The destination may be censored.  AML will apply.   What's the difference with a bank account ?

[bitcoinissatan]

What is segwit?
https://www.youtube.com/watch?v=P1ah5V10DP8

[AliceWonderMiscreations]

I don't mind SegWit and LN - I really don't.

They should used because users want to use them, not because they are the only way to get a transaction that costs less than $5.00.

The only way we the users (merchants and consumers) have a choice is with bigger blocks. Keeping the blocks too small for the network isn't letting us choose, it is demanding we either adopt LN or adopt an altcoin.

BU is the users fighting back, saying that is not an acceptable way to treat us.

-=-

The core developers may be exceptional coders, but if they are ignoring the real world issues that exist and instead are trying to force us to use a solution the company they work for is financially invested in, that's authoritarian - it isn't choice, and I won't be a part of that. I'll choose the code by coders who are not authoritarian.

[dinofelis]

I don't mind SegWit and LN - I really don't.

They should used because users want to use them, not because they are the only way to get a transaction that costs less than $5.00.

The only way we the users (merchants and consumers) have a choice is with bigger blocks. Keeping the blocks too small for the network isn't letting us choose, it is demanding we either adopt LN or adopt an altcoin.

BU is the users fighting back, saying that is not an acceptable way to treat us.

-=-

The core developers may be exceptional coders, but if they are ignoring the real world issues that exist and instead are trying to force us to use a solution the company they work for is financially invested in, that's authoritarian - it isn't choice, and I won't be a part of that. I'll choose the code by coders who are not authoritarian.

I think you think too much that there are "important people deciding".  If you think that, you think that bitcoin is centralized, with some hierarchy that makes "political decisions", like in the fiat world. 

We are just witnessing a dynamical system that *takes its own decisions*, without "important people" or "a hierarchy" deciding rationally, and that was the whole point of a trustless, distributed consensus system: the consensus emerges from a dynamics, and not from some central authority.

It is like a free market deciding on a price.  There's no authority to turn to, or hierarchy to try to talk to, if "the price isn't right".  The price is a dynamically established phenomenon that nobody in authority, decided upon.

In the same way, the consensus over the protocol in bitcoin is, in as far as bitcoin is a decentralized consensus system, just as dynamically determined as the price in a free market with many actors.  Wanting some price settings is wanting an authority, a cartel, a monopoly or something of the kind. 

Of course, like a free market, "market makers" try to set the price to their hand.  But in as much as there are sufficient diverse players in a market, there are no strong market makers that decide upon the price.

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.

[AliceWonderMiscreations]

If you think that, you think that bitcoin is centralized, with some hierarchy that makes "political decisions", like in the fiat world. 

Development of the software IS centralized with blockstream / bitcoin-core.

[fkod]

Bitcoin Unlimited and SegWit both of them have advantages relative to each other. No easy to decide choose one.

[franky1]

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.

[dinofelis]

If you think that, you think that bitcoin is centralized, with some hierarchy that makes "political decisions", like in the fiat world. 

Development of the software IS centralized with blockstream / bitcoin-core.

Nah, it is open source, everybody can make his own node software.  I suppose that mining pools do that, in order to implement their mining strategies.

[AliceWonderMiscreations]

If you think that, you think that bitcoin is centralized, with some hierarchy that makes "political decisions", like in the fiat world. 

Development of the software IS centralized with blockstream / bitcoin-core.

Nah, it is open source, everybody can make his own node software.  I suppose that mining pools do that, in order to implement their mining strategies.

That's like saying CentOS development isn't centralized because its open source.

Anyone can make their own software, but no one has the software distribution channel they have. They still decide what goes into the clients that the majority of people use.

The open source nature allows the community to have a chance to change that - and that is what BU is all about, an attempt to change the centralized development of the Bitcoin software.

[Hexadecibel]

Seems to me that the tide is turning in favor of BU.

Funny how markets work.

[franky1]

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.

[dinofelis]

Anyone can make their own software, but no one has the software distribution channel they have. They still decide what goes into the clients that the majority of people use.

Well, normally, the protocol is protected by the consensus mechanism that imposes immutability, that is, status quo.  So the software will not be able to change the protocol.  That is what we are witnessing.  We see that the dynamics of the consensus mechanism is such, that everything evolves in such a way that nothing happens.

[jonald_fyookball]

Anyone can make their own software, but no one has the software distribution channel they have. They still decide what goes into the clients that the majority of people use.

Well, normally, the protocol is protected by the consensus mechanism that imposes immutability, that is, status quo.  So the software will not be able to change the protocol.  That is what we are witnessing.  We see that the dynamics of the consensus mechanism is such, that everything evolves in such a way that nothing happens.

When things get bad enough, change happens... one way or another.

Kind of like an alcoholic hitting rock bottom.