Bitcoin Forum

Let us try an new perspective to the whole block size debate.
Two scenarios i like to discuss.

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

2. SegWit gets the support and we all soft fork to SegWit, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? A hard fork? Can we still go to BU at this point? Something else?

BU breaking is guaranteed, 100%. It's design basically is an attack waiting to happen.


Segwit breaking isn't guaranteed, but not impossible.

as unbiased as possible

with BU
users still use native keypairs. the thing is when a hard consensus activates a bilateral split does NOT occur... also pools WONT jump straight to filling a block right to the top of the limit. they will try a block at 1.001mb first and see what the orphan risk is. and progress from there. it may take hours or months depending on safety/demand for it to actually hit the new limit.

so lets say there was issue with blocks over 1mb.. pools simply mine 0.999mb blocks again.. end of drama



with segwit
SW positions pools and segwit nodes as upstream filters and users need to move their funds over to segwit keys to actually be disarmed from the mallicious things that segwit meant to fix.
so lets say there was an issue with segwit. all the pools and nodes need to down grade back to native nodes and find a way to move funds back to native keys.

I used ZeroBlock app on my phone to kill time. 

saw a content item (swipe left) link, about segwit issues blog post.

1) user asked for a link to explain "what's wrong with segwit" maybe on reddit
2) child post provided link to GoT character avatar ("a girl has no name" guy) posted blog entry listing issues in a rather factual method.

trying to find now, and not coming up in ZB.   would post for refernece, but can't find.  have you seen this blog?

I have no idea what you are talking about, but i wounder that besides franky nobody could answer this. Usually the users on this forum act like they now it all. 

Lauda's Face when she read your statement.  :D

https://i.imgflip.com/n9nqw.jpg


 8)

FYI: Lauda trying to think of a response to Segwit breaking.
http://www.blogcdn.com/slideshows/images/slides/369/972/5/S3699725/original.gif?v=1

Can you explain why BU breaking is guaranteed? and Segwit is not?

Trying to answer that at least partially, from a "advanced non-programmer's" point of view (techies may correct me):


In this case, I think there would be no problem to "go to Segwit", as Segwit is not tied to a certain block size. What must be done is a "BU-Segwit" transition version that enables the Segwit soft fork in the BU code and possibly goes back to a static block size, so at the end all more or less would be the same outcome than without the BU intermezzo.


In this case, it's similar but a little bit more complicated because Segwit changes the block structure. We then cannot go back to the BU we know now, but we could go on with a BU fork that includes Segwit. So the outcome could be a client with the BU blocksize consensus mechanism but Segwit cannot be "erased" that easy from the code.

In the end, we are dealing with a piece of code. There has been "flaws" in Bitcoin before and it was rectified. If ArtForz wanted to take all our coins in the early years, then he could have done that, but he told Satoshi about the flaw and he fixed it.

This is the thing about Bitcoin, if it fails, we all lose money. A consensus about the critical change that would be needed to "fix" it, will receive quick consensus once it was published, because it will be in our best interest. ^smile^

A lot of Peer review goes into this code, because it is OpenSource, so chances of "critical flaws" being identified is reduced.

bitcoin almost failed in the past, remember the 2010 bug? but nothing really happen to its value, the marketcap is way too big now to simple fail because someone is not in agreement

in the worst case it would remain as it is now with the 1 MB block, without the possibility to scale, miners actually are not against segwits but more against LN, they think that segwit will lead to LN eventually

bitcoin unlimtied my look like a fork but unless i'm missing all the change it's just look like the first client version with the 32MB limit

BU has known attack vectors, it's part of the BU "design".

The BU concept is presented as that everyone is perfectly rational and has perfect goodwill towards BU, and so picks a sensible figure that everyone can handle. The reality is the soft 16MB limit can be quickly and easily reached if someone malicious floods the network with 16MB signalling.

Also, BU wasn't (in the past) programmed to follow the longest PoW chain. That would cause the BU blockchain to fork spontaneously into different blockchains as long as there's sufficient disagreement between the nodes about what the blocksize should be (a minor incident like this happened recently with a BU mining node, implying these kind of risks are still programmed into the software not as a bug, but as a feature).



Segwit has an attack that can be easily stopped: sighashing attack can be performed on the 1MB base block (and not on the 3MB of witness block).


But that attack can be done today without Segwit, but it's not being used, because it's not very effective at this scale. And miners can easily detect transactions crafted to attack in this way and simply not confirm them in their blocks. A malicious miner could still include them, but that will still be as ineffective as the attack is today, as it's identical (only the 1MB base can be attacked).

The problem with Bitcoin Unlimited if it "breaks" is it will have "not as good" developers. All they great thinkers in Bitcoin is at Core and all the good contributers support Segwit in my opinion.

I think the 1st option would be madness and would probably destroy bitcoin.  The idea that we can move to a completely new consensus method and that it not have problems is to me just ridiculous and also leads to far more control for larger miners.  What i learnt yesterday about attack blocks and how long they can take to validate is another problem.  Just research it if you havnt heard of it before.

The 2nd option is the sensible option and it has been thoroughly tested by the core devs,  and i think that if there was a problem with the softfork it would be fixed rather quickly, due to the fact Core has such a massive dev team compared to BU.

IF BU Fails the Transactions problem will never be fixed.


If Segwit Fails, EVIL BTC Core Dev will not be able to Steal transaction fees away from the Miners.
And LN will not become a fractional reserve style system that BTC Core totally controls.
LN will not become Crypto banking 2.0 and we keep the dirty bankers out of crypto until the slick bastards make another attempt.  :P


 8)

FYI:
IF BTC Core was worth a crap ,
they would release a hardfork with a simple 2MB blocksize instead of letting the fees skyrocket and transaction delay for 3 days.

I think youre misinformed or youre misinforming others about the Lightning Network. BTC Core doesnt have a monopoly on what layer is built on the network if segwit is activated. There are other groups who are already coding other executions of it.

its called a sybil attack.
a malicious core loving pool can also sybil attack with loads of core nodes flooding the network and then make changes too..
same thing. nothing specific that is only attackable via BU

nope
learn consensus and orphans
and that block was orphaned in 2 seconds

orphans happen daily. orphans are a protection mechanism. orphans are good. yes it causes drama but the end result is a single chain

pools know orphans have a positive job of cleaning up the disagreements. pools also know they cause drama for the community so pools usuallly dont do anything to cause much drama.

hense why pools would take baby steps, testing the water and seeing how much orphan drama is or is not caused.

I think if you bothered to study Segwit & LN and study the history of Banking, you might have a clue to how much they are going to Dominate BTC if segwit is activated.
Start with the LN white paper, then google the history of how fractional reserve banking began, then do something really hard Read them and then think on it.  ;)

 8)

just to clarify kilo's point because he appears to be a hott head that runs in different directions rather than explaining the point rationally

pink flower said

well core have already positioned themselves as a ringfence around the pools with their "fibre" nodes.
if pools adopt segwit then the segwit pools will white list the "fibre" nodes as their way to maximise propagation efficiency.

segwit is known to blacklist nodes they dislike and whitelist other nodes. known to not relay certain transactions.

 so they can be biased against any smart contract that is not produced by LN(blockstreams version of second layer smart contracts) by  not relaying those to pools.
causing the issues for opposing second layer services by not being able to settle or set up channels in a timely manner. because their transactions will not be added to pools mempool or refused to enter a block
(much like core loving pools refuse to do 'first seen, first added' for transactions. and instead biasedly add transactions by who sent it and how much is paid(BTCC does this))

with core being the upstream filters (gmaxwells own words) and also demonstrated in cores own userguide.. core have set themselves up to centralise the network.

try reading the documentation and code whilst wearing a critical /logical thinking cap. and not a fanboy cap.
dont think about the limited benefits, promotional sales pitches.. look for the fine print limitations and realities.
EG
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
meaning you have to have a segwit node. to be able to be accepted by the other nodes.. and you are then able to whitelist your own non segwit node. (basically other peers will reject you unless you pretend you are a segwit node)
https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg

if you think the image is some anti core propaganda wallpaper from reddit.. check where the image is coming from (hint here is the link)
https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg

there are other little tip-bits of agenda hinted at in the userguide. how segwit will reject blocks that are not produced by segwit pools ensuring core has control of the network

---

oh and by the way.
when pools make segwit blocks.. they wont be organically backward compatible. they will need to be 'filtered' to be presentable in a manner old nodes can understand.

meaning if segwit has a bug. the you cant just turn off segwit nodes and go back to old nodes which will understand the blockchain.
pools then have to do the filtering of the blocks while they too downgrade which can cause alot of disruption. due to them having to move funds back to native key types and other things to undo a segwit activation

where as a bu pool simply make blocks under 0.999mb without needing to downgrade/filter or move funds back. because BU uses the same mechanisms and transactions that were around for 2009-2016

---

p.s
if you feel my post is just a wall of text and you have not bothered reading it simply because its a wall of text. then you obviously dont have the concentration span to read userguides or code. this lack of attention span reduces your ability to understand bitcoin fully, so work on it

If both should fail it means we wouldn't get a shot at addressing the confirmation times and high fees issues that we find ourselves in so at least one should get the support for us to either try a hard fork or a soft fork of the Bitcoin core. I'm just for the change and not necessarily BU or segwit.

Now this is the discussion i was looking for. I've some questions, but i make a research on my own, since right now i have a more important question, let me first sum it up as i see it.
Both solutions bring dangers with them. Regarding BU people are more concerned about the risk of an technical problem. In case of an Problem another hard fork could quickly resolve the problem.
With SegWit the concerns are more political. SegWit per se may not be dangerous, but it could open doors for the privatization of Bitcoin. This could make Bitcoin controllable by few and goes against one of the main principals of Bitcoin. I think many argue here that just because one can act bad (not in Bitcoins and it users interest) doesn't mean he will do so. To which the classic answer would be that if it's possible, then people will do it (act badly ).
Also SegWit is a soft fork, but going back from it seems not to be so easy.

Seeing this i wounder why there is no big support for a third solution. Just buy some time by increasing the Size to 2 or 4 MB and look for a better and more permanent solution.
I see why both sides would prefer to see there solution implemented and therefore pushing for it, but i feel like this is one of those situations where you should stand back for the greater good.

You don't mean privatisation, Bitcoin is already privately owned (in a similar way to how shareholders own businesses)

Your suggestion to "just" increase to 2-4MB is bizarre.

1. Validation attacks on blocks more than 1 MB mean Segwit is needed before any blocksize increases
2. Segwit increases the blocksize to 4MB anyway



Some claim that limiting sigops on both the base blocks and the witness blocks is a workable solution to validation attacks, but this could prevent the witness blocks from reaching capacity, making some part of the 3MB witness blocks redundant.

Claims that attacking non-Segwit addresses are equally incorrect; that attack can be performed today. It doesn't work at 1MB, so no-one tries. After Segwit activation, the situation will be identical to today; only the base 1MB can be attacked with a sigops validation attack, not the witness blocks. Miners could detect and drop transactions that attempt validation attacks.

^ look at him talking about something he doesnt understand

segwit only works for people using segwit keys. anyone sticking with native keys can still cause signop issues within blocks.
the only way to avoid sigop issues in blocks is that 0% .. ZERO .. again ZERO(emphasised 3 times) users have funds on native tx's.

segwit does not disarm native transactions so sigop and malleability will continue.
segwit only disarms the innocent that voluntarily move funds to segwit tx's.. it does not disarm the malicious users

segwits 4mb wight is not a real 'feature' that all bitcoin users get to benefit from.

firstly only IF 100% of users use segwit keys, they would notice about a 2.1mb transaction one time boost.
the other 1.9mb is spare and unusable for anyone until future features ar added that append trivial data to the end of a tx for things like
confidential tx's

if the base block sticks to 1mb. the max expectation is ~4500tx with 2.1mb weight.
then if confidential payment codes and other features append data.. its still 4500tx but bloated to take up the spare space of the 4mb weight

The opponents of BU are small block advocates that prefer the average user be
able to run a full node than be able to transaction on chain and are more
concerned about having transaction fees pay be able to pay for security
in the future even though that concern is decades away.

While I fully disagree with both of those reasons, at least they have some inkling of plausibility.
However I haven't seen any credible argument for the possibility of a technical problem with BU.

 

FTFY

I was attempting to be diplomatic and impartial...but thank you :)

LOL, and you call me a hothead , my pompous comrade.   :D


 8)

FYI:  In the Words of Hot Rod, May God Rest his Soul.
http://www.azquotes.com/picture-quotes/quote-i-came-here-to-chew-bubble-gum-and-kick-ass-and-i-m-all-out-of-bubble-gum-roddy-piper-56-37-20.jpg

Actually it would make more sense to increase the blocksize First before ever adding segwit.

Your Saint G.Maxwell has been quoted in the past saying blocksize increases would be needed after segwit.

I will tell you why they should do it first, their is a Security vulnerability in the LN whitepaper,
where if you can trigger a delay in the Blockchain's ability to process transactions , you can delay LN, until the timelocks have been released
and wait for it .............. STEAL THE BTC RIGHT OFF OF THE BLOCKCHAIN!!!

Larger the blocksize the safer the community from that direct vulnerability.  :)

So Blocksize should be increased first, but they know no one wants segwit and would ignore it completely ,
which is why all of this effort to force it down everyone's throat.   :P

 8)

FYI:
Segwit 4MB is not the same as a 4MB blocksize increase.
Segwit only gives a usable 1.7 MB of the current style blockchain which is theoretical , (may be higher , may be less.)
A direct 4MB blocksize increase without segwit would give 4X the current transaction capacity, which would actually hold BTC for years and keep transactions Onchain and completely avoid LN Offchain Counterfeit coins.

I admit that I still try to wrap my mind around the technical discussions about Bitcoin but knowing that there is politics involved here still makes me doubt what the hard fork to BU, Classic or XT is really all about. There has to be something like a power grab here. Also the argument that the Bitcoin Unlimited developers are not as good as the Core developers and contributors deserves notice.

until you read the code and grasp the concepts of bitcoin. you will be stuck in the social drama of politics.
dont be so easy to grab onto some human and kiss their ass because of X or Y.
one day that human wont be here, but bitcoin will. so care more about bitcoin and less about the human

learn what the code does and let the code help you make your decisions.

core code is not a simple fix. its about changing the network topology and favouring nodes (centralising)

other implementations such as xt, classic, bitcoinj, btcd, bu and half a dozen others  are not about kings or gaining control of the network. they ALL want to use consensus to have all implementations on the same level playing field where nodes have the independent decentralised power, not devs not miners.

the whole point of bitcoin is that its not reliant on some central team of decision makers

so instead of playing the social games of which team is better. instead think.
let there be many teams so that none have power and only the nodes form a consensus of what should move forward.

that way the 'teams' become more like workers rather than managers. where the teams work to find the best solutions to bitcoin problems. instead of fighting to be kings and herding sheep in only a direction they want

Ya think?   :D

Ask yourself: What company raised $71M in venture capital, wants to be "a leading provider of blockchain technologies", and hired many
of the prominent developers of the core bitcoin repository?

hint: It rhymes with "cock dream".

You do not know anything - poor mate.

'Saint' can be called s.o. who is already dead  ...  banned is not enough.

 ;D

@hv_
Were you born this stupid, or do you have to work at it.   :D

 8)

FYI:
It was used as a form of parody, Dufus.  :P
Implying that CB Worships G.Maxwell believing all of his lies as gospel.

I'm just PoSting this shit to match your quality expectations - no PoW needed for you . sorry

I have no expectations of you , I know you are stupid.  :D

 8)

BOOM BABY !!!

And there it is !!  :D :D :D


Gavin Andresen: “Run Bitcoin Unlimited” To Solve “Destructive Congestion”

https://cointelegraph.com/news/gavin-andresen-run-bitcoin-unlimited-to-solve-destructive-congestion



and what does he think of Segwit.



 8)

the ~2.1mb POTENTIAL that segwit offers is:
only 4500tx/~2.1mb IF 100% of users have moved funds to segwit keys. and continue to only use segwit keys (not gonna happen)

its not going to change right at activation day.
its not going to change just by using a specific node.

it will only change when people move funds to a segwit key and then use segwit keys only,
and only grows at small amounts depending on how popular the use of segwit keys are UPTO the max POTENTIAL

---

so lets explain it. in regards to impact on tx demand

the mempool is nearly always well above 4500tx of unconfirmed tx's(2mb) in the mempool.
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year
ever since october the lowest the mempool has been was 3mb+(meaning 4mb DEMAND if you include the 1mb that do get confirmed)

there is also currently 47million unspent outputs that would need to be spend to move everyone over to segwit keys
http://statoshi.info/dashboard/db/unspent-transaction-output-set

---

so even if segwit activated lets say tonight.. nothing changes.
lets say people downloaded segwit nodes and took a few days to sync
and then lets say EVERYONE (even the holders from 8 years ago) moved their funds to segwit keys.

do you understand the congestion it would cause to get funds moved to segwit keys before full benefit of segwit can be seen
imagine it everyone trying to move funds all at the same time...

---

then once everyone moved across.. that >3mb+(average demand) after everything has cooled off, results in still not enough even with the 1.1mb extra "boost" segwit offers

however just increasing the blocksize to 4mb without the bait and switch will alleviate things and people dont need to move funds to special new keytypes to see the benefit.

---

segwit REQUIRES people to move funds to new special keypairs that are not tested on bitcoins mainnet and do offer a new attack vector by manually copy and pasting the segwit keys from a segwit node to a native node and then messing with it as a 'anyonecanspend'

yep core might filter out tx's being sent automatically by a segwit nod to native node. but they cant stop manual copy and pasting between a segwit node and native node.

---

in short. segwit opens up new attack vectors. doesnt guarantee 100% utility of segwit and doesnt disarm the malicious users.

p.s my over use of HR lines are for those with short attention spans who fail to read code/literature about how bitcoin works simply because 'its too long'

Gavin rules.   

It really boggles my mind why people are listening to people like Gregory Maxwell over Gavin.
I think taking $71M in venture capital is a far more reliable indicator of a biased agenda
than 1 visit to the CIA.  Call me crazy.



 
 

Again it is all politics. Gavin started playing the game when he started campaigning for XT. Maybe he thinks he can reenter the scene when the network does the hard fork to Bitcoin Unlimited. All their moves always have a hidden purpose.

If you think about it both sides are doing the power grabbing depending on your point of view. On one side it is Blockstream and on the other it is Roger Ver and the Chinese miners who are supporting Bitcoin Unlimited.

no they're not.

xt, classic, bu and the other dozen nodes want ONE network where everyone is on the same playing field and using consensus.

its only blockstream that have bypassed real consensus by going soft.
its only blockstream that have nodes set up as upstream filters to control what non segwit nodes see/receive
its only blockstream that have played around with its banning and whitelisting protocols.

here is gmaxwell trying his hardest to get those not wanting to follow gmaxwell to split away.. but they laughed at him and refused to split away because that would just give gmaxwell what he wants..



READ CODE, read stats,
stop defending the humans


X% are with segwit
X% are with BU
X% are with classic
but ~60%.. yep well over 50% are UNDECIDED

so do not classify the 50-60% undecided as being in any camp just to suit some biased brand camp social games

Because this does not fit Blockstreams agenda to implement the Lightning Network. Their investors wanted them to come up with a long term solution for scaling Bitcoin and not just a temporary patch. A lot of salaries were paid to develop this solution and a lot of pride is involved too.

So in the end, it boils down to money again and not what the people wants.

The miners wants miners fees in the future and they do not think running payment channels off-chain will sustain their business in the future. < money again >

check out the unconfirmed
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year

apart from a blip in june/july (ill get to this later)
mempool size was 2mb-3mb..

then in october. (around the 10th october) it started to get into 4mb.. and started rising...and rising. and rising.. hmmm i wonder what new feature was introduced in october that needed the community to get frustrated and delayed to "sell" the community into thinking this feature being the promise to fix the issue..

hmm.. oh yea.. segwit.

as for june july. (CLTV+CSV)

what a coincidence.. spam attacks right around the times blockstream devs want pools to think certain features need to be added to be stepping stones to something that (may) eventually fix spam attacks..

If neither happens, bitcoin core is just fine with the current block size. They likely
would never have moved to even seg witness yet without the push for bigger blocks

Their viewpoint is 1mb blocks are just dandy, because btc is mainly a store of value
and currency is not relevant as long as price goes up.

Thus this impasse will likely go on for years as long as BTC price rises and continues to
act as bitcoin core assumes, as store of value, that continues to rise steadily.

Impasse/stalemate

There are no clear consensus to Bitcoin scaling problem but whether BU or Segwit will not be implemented for now, will not be a problem in Bitcoin cause this currency will still move forward.
The bitcoin network can still handle the volume of transactions in a daily basis with the drawback to pay high fees in order for your transactions to get confirmed faster.
I think this problem will remain for many years if the community continues to debate and argue for better solutions.

If by "not a problem" you mean its ok for Bitcoin to possibly lose opportunities for investment, mainstream adoption, and continued clear dominance as the #1 crypto, then sure, its not a problem.

Just seems to me that where the current bitcoin core devs seem to think. Thus gridlock. But more daunting is no one is talking or trying to solve the issue on one or both camps.

Again...frigging stalemate :(

High fees are holding Bitcoin back (and i don't mean the price). They make micro payments unattractive/unpractical.
Maybe many are undecided because they rather remain in the status quo than see Bitcoin fuck up.
The agenda of core/blockstream is clear and whether there points are right or wrong, i don't expect them to compromise.
I don't see however the reasons for BU to not compromising. Many of them seem to care about Bitcoin and want a good solution.
The emergent consensus seems to be their biggest hold up. Why are they still pushing for it. Why not just go for a quick increase of blocksize to 2MB? Try it on for size, see how the network acts, which would be valuable information for further increases. It would be a small but immediate and safe relief and it would buy time to test the emergent consensus more or look for different options. I'm sure this would also attract a bunch of developers to this solution. I'd expect also many undecided to jump on that wagon, so why doesn't BU compromise to this? What are there reasons to push fore there solution without compromise?

So the end game of that scenario is like:

BTC price is e.g. 2Mio $
TX fee e.g. 1000$

With that only big guys will transfer = banks and funds, or better hodl in their core funds.

We see it today, with Vontobel BTC tracker it is cheaper to transfer the tracker using e.g. SWIFT

So we need middle men and can not own BTC any more but have to buy IOU to participate in this store of value.

Do you think thats the future?

No idea...but for some reason bitcoin core devs feel it is just dandy to sit on hands and have a 1mb block size and look at btc as a store of value

on the other side

they feel it is just dandy to not get seg witness now and fight the up'ing in block size later (past 1mb) with bitcoin core..because they see it as

their only leverage with bitcoin core for any movement

So bitcoin core won't hard fork and those not wanting bitcoin core won't let the btc core developers have the lead and allow a soft fork

it is quite the cluster

 

Looking at the network topology of the segwit softfork, it looks horrible. The idea that there is a mixture of nodes, some with full network knowledge and some without full knowledge of it if they don't upgrade is asking for complications in my opinion. I wouldn't be surprised if some of franky1's concerns are true, but cannot confirm this as it is way beyond my technical knowledge and expertise in this area.
Perhaps this should have been implemented as a hard fork along with the 2MB block size increase as originally agreed. If the miners and exchanges are behind a hard fork, the old fork is a stuck difficulty chain with coins that cannot be traded.
Even if the future is that the main chain is more of a settlement chain, with lightning style networks providing retail functions, there still needs to be an ability to grow the chain to meet demand. Some alt coins (e.g. Komodo) are now using the bitcoin blockchain, increasing demand. I don't see why some algorithmic block size change can't be implemented. It could look at parameters such as high fee / low fee unconfirmed transactions, past block usage, orphan rates, etc. and slowly adjust, monitor effects and adjust. Then a sensible fee market could develop, rather than this pathetic fee race or drop out due to expense situation we have now due to a fixed block size. A fee market cannot develop on a full block chain, it just limits use when it becomes to expensive to transact.
I'm not surprised the miners are upset with core / blockstream developers for not keeping to their word and implementing segwit as a hard fork along with a much needed and conservative 2MB block size change. So perhaps it is stalemate until we see which economic power goes bust first.

FYI, franky has been having his "concerns" for 3 years and counting.


Do you know what happened to the issues that Franky used to complain about? He no longer complains. Because they were demonstrated to be unproductive trolling. When he finds they don't work, he simply switches to newer trolling strategies instead.

If you'd believed anything Franky had stated or predicted, Bitcoin would be hugely unsuccessful cryptocurrency with all the users abandoning it in fear and frustration. But it keeps becoming more popular, and more successful.

concerns years ago. blockstream take over.
community wanted onchain scaling with dynamic blocks and compromised down to initially 2mb dynamic in late 2015..

yes carlton too wanted dynamic blocks aswell, funnily enough
^ one of many examples


blockstream devs LukeJr and Adam back said they will do their part....
spring 2016.. they backtracked and now we are left with their empty gesture that is not even a guaranteed or real expected fixed 2mb. let alone dynamic
and instead an attempt to get their nodes at the top of the network topology (upstream filters)

their 2mb boost wont occur, the other fixes wont occur* and we are still left on the reliance of them spoon feeding out code rather than let the nodes independantly set the limits and use consensus to set the overall rule.
*(needs users to move funds to segwit keys and only use segwit keys to achieve anything, but doesnt fix/prevent the native key users = problems not solved, solutions not achieved)


thre was a compromise.. the consensus roundtable of late 2015.. the community settled on a 2mb starting point but wanting it dynamic so that we didnt need these "human" meetings and instead could let the nodes decide what node can cope with and then the pools produce blocks within what nodes can tolerate.

but guess what blockstream backtracked and pretended they are not involved that much in core and cant code a solution.
strange thing is that thee late 2015 consensus event should have just invited the blockstreams office janitor instead and that probably would have been more productive

So if the 2015 consensus event was adhered too, we would have the best of both worlds. A hard fork with dynamic block solution, and a simplified and more effective implementation of segwit allowing for full steam ahead for those wanting to develop lightning networks.
Instead we have sectarianism and deadlock, one which the miners can quite happily sit out.
And in the meantime, bitcoin adoption suffers.

Is this a good summarization of the situation?

your forgetting that all the complaints to blame miners is also due to blockstream

if it was a full hard consensus (nodes first then pools second) the nodes would upgrade and given confidence to pools to then vote second because the pools would know that node could cope with it.

but blockstream devs envisioned going soft and gave only the pools the vote.. emphasis blockstream devs gave pools the vote.

but the pools are smart to not change anything without nodes being there to accept the change, so the pools are waiting undecided. the only pools voting for segwit are BTCC and slush which are if you research their VC funding BTCC are funded by the same guys as blockstream. so its obvious why BTCC jumped right onboard the segwit train before thinking about the pro's and cons to the network effect or if segwit would actually solve issues for the whole network.
http://dcg.co/network/#b  <- blockstream, BTCC

What i could condense from the arguments of core/blockstream is that they are afraid of the dynamic blocksize, because it would give miners to much power. So what do they want now? Set them themselves instead of meetings or a dynamic?
What is the reason for BU to hang on to the dynamic? Is it only because they don't want these meetings too? To avoid to hard fork to often?

dynamic blocks DO NOT give pools the power.
node consensus is the power. and pools know that.
pools could produce any blocksize they want but if nodes orphan a block... that block is metaphorically in the trashcan. thus pools wont do things that waste their electric and time.

dynamic scaling works in a 1,2,3 step bases.. the blockstream 'dynamic is doomsday'ers however twist the logic of reality and talk about the 3,1 fake methodology(backwards and skipping a step) which is not how it will play out, but helps them scare the community into thinking that without the blockstream devs spoonfeeding and without king maxwell standing on his mount preaching the rules, bitcoin would break

blockstreams soft fork gave pools the vote so that if it succeeds in activating. blockstream take the glory. if it fails they have the bait and switch to blame it on the pools.
(typical banker economic illogic: if economy rises bankers celebrate their greed saved the economy. if it fails, blame the poor)

Here is the part where i'm confused. The argument goes like this. We have dynamic blocks and there is a 2.5MB blocked mined. Node A sees it as invalid and drops it, but node B and C accept it as well as all Miners. Bitcoin will built on this block and Node A will have to accept it or fork. Right?

Now we have the same scenario but Nodes A and B (the majority) rejects the block and only Node C and all miners accept it. Wouldn't this mean we would still built on top of this 2.5MB block and lose 2 nodes? It's an invalid block to the majority of Nods, but they have no miners behind them, so who is going to mine for them? Wouldn't this situation be technically considered as a fork?

1. thats where your skipping to step 3..
three step process based on your 2.5mb scenario
step one
92% of nodes say 4mb is fine...(reality is a mix of more than 4mb to lets say 16mb)
1% of nodes say 3.6mb is fine
1% of nodes say 3.3mb is fine
1% of nodes say 3mb is fine
5% of nodes say 2.5mb is fine...
^ the nodes 'consensus.h limit'

but ALL nodes then have a policy.h limit too which is at 2.5mb


pools too have 2 limits. they see the 95% 2.5 limit and that becomes the POOLS consensus.h limit (2.5)
pools then have the policy.h limit where they make blocks at 1.001mb to test the water, see the orphan risk rate. if fine they then move to 1.002mb and it grows from there..
DO NOT think pools will jump straight to 2.5 or 4mb instantly

step two.(2)
as the blocks get to 2.5mb. orphans start to occur(due to A). but at an acceptable 5% risk tolerance. meaning the 5% (node A) rejects and has to choose to either move up its consensus limit to allow the policy limit to have some wiggle room or be left unsynced with the network.(3)
pools then decide if they move their limit up to 3mb consensus.h and try 2.6mb policy.h (depending on orphan risk)

step three.
by nodeA continuing to run but not moving the limit.. if blocks got to 3mb.. the orphan risk goes above 5% and pools start to get worried and stop growing. because network consensus is no longer at or below 95% tolerance

by nodeA continuing to run and moving the limit.. if blocks got above 2.5 but only to 3mb.. the orphan risk is below 5% and pools continue
by nodeA not running.. if blocks got to 3mb.. the orphan risk is below 5% and pools continue

3. defining your understanding of "fork"
the node if not moving its limits. is just going to continue rejecting blocks(left unsynced) its an ORPHAN EVENT.  or it switchs off its node.

by continuing to run but not upping the limit. it and other nodes where by the network goes under 95% would stop pools from growing.

the thing most forget is that there are 2 'limits' not one.

now..
lets imagine there was a pool that separately dcided it wanted to hlp node A by not following the network dynamic consensus. and dropped down to 2mb to mine for node A.
again an orphan event. this time also affecting the pool aswell(2 opposing pools fighting for blockheight of a single chain)

to cause a altcoin (bilateral split) node A and the pool will have to intentionally BAN the other pools and nodes to avoid the orphan game of consensus and then they become their own little network we would probably call 'clams 2.0'

the thing most forget is that even in a soft fork event nodes can ban opposition and cause a bilateral split (altcoin maker). even gmaxwll admits to wanting this to happen for certain reasons

No.

The 2015 agreement said nothing of the sort. The agreement was to implement Segwit first, then expand to 2MB base later. Nothing about dynamic sizing was part of it, that claim has been invented out of thin air.

First of all thank you for a better explanation than i could come up with. I do have to miner questions i'm not sure about if i got it right.
1. Regarding step three. Can the node with the lowest consensus.h limit hold back/block the network by not upping the limit while still running?
2. Regarding the bilateral split. Why do the Node and the pool need to intentionally ban the others to become a small network of their own? I thought this happens automatically since they assume they have the longest legit chain.

1. if nodes and pools decide 95% of the network is the metric then it requires 5.01% of the network to hold up block growth with 5% possible orphan heaches. if 75% of the network is the metric . the 25.01% of the network is needed to hold back growth with upto 25% orphan headaches if pools tried to exceed limits.

what you need to also take into account is nodes might have 75%-95%.. but pools may also have their own safer metric to reduce orphan risks

EG nodes at 75% where consensus.h 4mb and policy at 2.5mb
EG pools at 95% where consensus.h 2.499mb and policy at 1.01mb

for instance. resulting in pools only making blocks 1mb-2.499mb before seeing issues and pools only moving passed 2.5 if 95% of pools agree and 75% of nodes agree..

2. if an orphan game results in bilateral split(it doesnt).. we would be having several altcoins being created a week for the last 8 years just because of orphans
https://blockchain.info/orphaned-blocks

orphans KILL OFF opposing blocks. to keep to one chain

to avoid orphaning a block. the nodes need to ban the opposition to not see/try syncing to oppositions blockheight and to successfully build their own.

othrwise they end up in orphan hell rejecting their own small network because its lower blockheight, to instead request data from the nodes with higher blockheight... but then rejecting the oppositions because although they have higher blockheight the data (blocksize) breaks the rules when they get that block they request..thus being left unsynced.

so it requires not connecting to that main chain. to avoid seeing it to then happily grow their own chain (as clams2.0)

remember ethereum was not a CONSENSUS fork it was a bilateral split involving banning nodes. hint: "--oppose-dao-fork"

1. I assume we could also downscale. If nodes lower their limit for whatever reasons (or new nodes with low limits get added to the network). The pools would adopt and make smaller blocks if the orphan rate would be to high.
2. I thought the difference between an orphan and an invalid block would be that an invalid block doesn't meat the parameters of the consensus. Whereas an orphan is a valid block that is just propagated at the same time with another and it is not sure which one will result in the longer chain. So invalid = fork and orphan =/= fork.

edit: just read your edit and this makes it clear clear for me. Thank you.

Let's see BU fork and let's see how they manage themselves without leeching off Core devs. But they are too scared to fork so they will keep using their shitty tactics. Jihan Wu is a disaster for bitcoin, I wish his stupid monolopy ended, but im not sure about UASF fixing anything in the long run.

If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration.
Also, there is a need for blocksize to shrink to stop the fee market tending back to zero when there is no or little block reward when volume drops. If BU doesn't do this then I don't think it is the right answer either.
It all needs to be a lot more automatic for me.

Here is a thought. Perhaps a good percentage of these undecided are not really undecided but just don't like the options available to them, so are happy to keep the status quo until a better solution is found, or perhaps that one of the solutions is better implemented?

there are many solutions. you just dont hear about them due to the censorship and hoops you have to jump through just to get a core dev to even class it as a bip on "their" bip wall.

and the social media trolling drowning out other methods of promoting one because "its not been reviewed by the blockstream gods"

recently gmaxwell handed the Bip reins over to luke jr but gmaxwell still moderates the technical discussion boards of this forum and works along side theymos in the reddit forum. and also admins the mailing lists. and has co-horts moderating the IRC.

so goodluck to anyone not ass kissing blockstream for coming up with anything new that actually gets passed the blockstream wall, and into the communities general acceptance

Talking about BU any further it's useless. BU will never work, the model is flawed, it leads to destruction, miners would be total bosses, more than now and now it's bad enough already. Jihan Wu would rule Bitcoin under the BU model, which is why he pushes it. Very sad..

do your research. stop reading the 20 second reddit scripts. your getting obvious

read code
learn consensus
understand bitcoin
stop defending humans

1. jihan isnt the mining king that wil own bitcoin.. please research stats not social media
2. pools are not the boss never have or will be. they are the secretaries.. nodes are the bosses and devs need to be reminded that devs are just workers
3. implementations that are not blockstream are not the ones wanting to be kings.
4. its actually blockstream that gave ONLY pools the vote over segwit.. yet a hard consensus is about NODES st the rules pools follow

Jap, i think maybe we should stop to talk about that crap (BU) and not respond to the trolls anymore (frany1).

BU is not an option and never will be.  

We should work towards bringing more power to the users, not to the miners, they are getting their fucking blockreward and should be fine with that. Nothing more and especially no ultmate decision power.
So UASF is maybe a way to go. The reaction from Mr. Jihan shows its a at least an option.


No franky im not interested in what you have to say, just STFU.

If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting).  This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks.

Here is an article that describes how this optional feature works:  

https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4

an invalid block = blocks that doesnt meet the rules (your understanding of not meeting the parameters)
a rejected block can be valid(data/rule) but for propagation or longer chain or other reasons it just doesnt get accepted.

an orphan is just an umbrella term.

EG real world.
an orphan is a child thrown aside and detached from its parent.
it can be because the parent is killed off.
it can be because the parent no longer wants to be linked to the child (gave up for adoption)
it can be force away from parent (social services removed parental rights)

so in bitcoin the umbrella term orphan, just means thrown aside..
orphans happen alot
http://blockchain.info/orphaned-blocks

but explanations as to WHY, vary. all you can see is what other child replaced it as the preferred child

the description of DYNAMIC BLOCKS i made in post #57 is the broader way of how nodes set limits and pools follow in regards to how consenus generally works for all of the different 'dynamic proposals'

BU(just one of many proposals) for instance has a little extra(which is about the Excessive block stuff). which would occur in step two of my broader description. which would as you say 'automate' to move the goal posts. thus if you have the right upper setting. will find that your node wont unsync and be left behind as much as you think

but like i said there is more then one 'limit' and also pools follow what nodes allow, not the other way round.

yes if your nodes upper limit is not that high then you have to check now and again that its still syncing.
but if your node has sufficient limits set and knowing that pools are not stupid to jump too high to fast (pools are smart to take small tolerable steps to avoid orphan drama as much as possible) you wont have to worry about checking often

LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx.

If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p

Some people want to automatically track consensus regardless of the size of blocks; other people want to hold firm on the size of blocks they will accept.  So we (Bitcoin Unlimited) allowed users to do either.  

BTW--Bitcoin Unlimited doesn't "activate."  BU nodes by default will accept blocks larger than 1 MB today.

No this is bullshit man, if you always want to stay sync with the network you have to set the litmit to unlimited. Maybe you have the time to sit infront your node and track the blocksize the whole day, but many surely dont.

So please just go away with your divergent consensus.

Good that a supermajority of the network is on core and will reject your altcoins blocks if a fork happens.

Bitcoin Unlimited simply removes friction from node operators adjusting their block size limits.  Everything that a node operator can do with BU they can already do with Core by modifying the code and recompiling.  If you think Bitcoin Unlimited "breaks" Bitcoin then you must think that the only reason Bitcoin is not broken is because it takes a bit of effort to recompile the code. 

Some more thoughts on the matter: 

https://medium.com/@peter_r/what-were-doing-with-bitcoin-unlimited-simply-6f71072f9b94

I would like to understand your point of view here when you say "giving all power to the miners".

Other than allowing the miners to come to a consensus about blocksize with less constraint, what power do you feel that BU gives to the miners that they don't already have?

Soft fork and hard fork have explained about the pro's and cons of each supporting their own group. Hard fork focus towards mining full nodes and transaction time. Soft fork focus towards the decentralization and the miners fee, so a common committee could resolve it.

Go look for yourself, BU is a complete shit-show: https://bitco.in/forum/forums/bitcoin-unlimited.15/

The look on your Face CB.  
When you realized I Tricked you into Bumping this Topic for the Last 30 Minutes.   :D :D :D

http://badhairdays.net/wp-content/uploads/2013/10/a2fqnzpciaazn6s.jpg?w=630

 8)

 :D :D :D
https://s-media-cache-ak0.pinimg.com/236x/93/02/ea/9302ea7f8e15e5d1c585d8433445ac38.jpg


 8)

https://news.bitcoin.com/new-unlimited-bitcoin-com-mining-pool-now-open/

Looks like someone is getting ready to help BTC Unlimited kicks Segwit virtual ass
Miners can earn 110% compared to other Mining Pools.

 8)

What's 110% of zero? :D

https://bitcointalk.org/index.php?topic=1804141.msg18095902#msg18095902

The look on your Face.   :D :D :D
When you realized Bitcoin Unlimited was Paying out more to their Miners that Segwit Pools.

http://badhairdays.net/wp-content/uploads/2013/10/a2fqnzpciaazn6s.jpg?w=630

 8)

FYI: Also when I tricked you into Bumping this Topic for 30 Minutes.   :D :D :D
https://bitcointalk.org/index.php?topic=1807251.msg18096423#msg18096423

You should break out the CarltonDance gif instead, as that's literally what I was actually doing ;D


Can you explain, lo-kicker, how the Unlimited pool will pay out 110% of anything when their blocks keep getting rejected? These people are going to have one nasty electricy bill to pay

;D

They will just add some more electricity costs (minor) soon running enough nodes... easy done.

If they're not making any BTC mining, they will have nothing to pay their bills.


The End. ;D

There's a company called Sock Bean?  :P

Well You are Awful Stupid, But I will give it a shot.

They will only produce blocks that are accepted by the entire network, until they have enough % to Take over the Chain Permanently .

Read the above again, I know you are slow in the head.

BTU could take over the network with between 51% or more and their ain't jack you or the BTC core devs could do to stop it.  :D

 8)

FYI:
BTU only needs ~25% more for the majority of the network to leave you and BTC Core Shenanigans behind forever.  :D
Odds are the Chinese Miners will join them giving them ~70% of the network.
BTU will have the Longer & Stronger Chain , Segwit supporters will buckle like the Chicken Little they are or fork into oblivion!  ;)

LOL,  :D
https://images.gr-assets.com/hostedimages/1394319819ra/8836023.gif

They can have their blocks rejected despite any of that.


Time to change your underwear, off you scuttle

Yeah , keep thinking that!

Just go home to your mommy, so she can soothe your fragile broken psyche.   :D

 8)

I was hear 3 years ago (may have been posting as FunkyRes) and I recall Franky's posts, hard to forget his awesome avatar. They don't seem that different now to me. Well there is a difference, I no longer am gunho about SegWit.

I wanted SegWit because I like the idea of micro-payments but I have since come to realize that micro-payments isn't what segwit is about and can be achieved by simply increasing the block size, which is the KISS solution to the problem. SegWit has a different agenda altogether and I do not believe it is in our best interests. It adds incredible complexity to bitcoin while taking control for the transactions outside the blockchain (via lightening) and I can not condone that.

I hope you are not supporting BU while claiming segwit adds "incredible complexity".

The only thing complex here is the ridiculous "emerging consensus" BU approach. Actually it's not that complex, it's pretty simple: BU doesn't work.

Segwit does, it has been tested to hell and back. Let's get segwit already you pricks.

on testnet.
thats like saying litecoin works because it has been tested since 2011.. but throw it into bitcoins mainnet overnight and see what happens when you try telling the world you can get to do litecoin stuff..

show me a segwit transaction on bitcoins mainnet.. oh you cant
show me a segwit block on bitcoins mainnet. oh you cant.

show me if segwit is so "backward compatible" how come no tests are done on bitcoins mainnet to show how "compatible" and "safe" it is.oh you cant.
show me segwit is letting nodes vote... oh you cant.
show me how segwit if activated stops native transactions.. oh you cant
although segwit removes automated relay of unconfirmed segwit tx's to native nodes, show me how segwit prevents MANUAL copy/paste of unconfirmed segwit tx to old nodes.. oh you cant

stop reading the 30 second elevator sales pitch of segwit and learn the real features learn the capability and their limitations and their effectiveness, learn the weaknesses, learn the loopholes and learn what it doesnt solve.

then your utopian bubble pops loud enough to wake you up

save repeating myself

I'd like to see more reasoned arguments for segwit, rather than just fanboyism or insult hurling.
I see more reasoned arguments against segwit, and about the need for a blocksize increase IMO.

So how will users be able to move small UTXO's from native keys to segwit keys without a blocksize increase?

And is an offchain solution really bitcoin, or a bitcoin facilitator?

no one is against offchain solution as a VOLUNTARY side service
LN does not need segwit.
LN can be just a side commercial service much like bitgo or coinbase.com.

but centralising the network where it forces everyone into using LN. BIG no no

LN has a niche that some can happily use. but LN has limitations too. not everyone will benefit from it even if forced to use it.
LN is not the end solution. so treat is only as a future side service

Neither has been tested on the main net.

Segwit is much more complicated which is why it required so much testing even on test net.
BU is by comparison a much simpler change.

@franky1 - can this quadratic spam you talk about be resolved on native keys anyway?

yep
reduce TX sigops limit. in effect much like not allowing 0 fee tx's into blocks. not allowing tx with XXXXX sigops into blocks

but thats a separate thing to what segwit does.. moving the signature= only segwit tx's are affected and doesnt do anything for native tx's

best analogy for sgwits proposal
"we fear people will want to shoot other people in the leg.. who volunteers to be amputated so they cannot be shot in the leg or run around to shoot others"

reducing sigops.. "is like a metal detector scanner at the door. if you have a big lump of metal on you.. you cant come in no matter if you amputated or full bodied"

Offchain can only ever be a representation of the value of bitcoin.
Just like US Dollars used to be exchangeable for their face value amount in Gold.

Both are only representations and not the actual item of value.

 8)

FYI:
Added details to Franky1 statement : LN does not need segwit.   :P

LN Does Needs Segwit so that LN can be trust less.
Otherwise LN requires a separate Trust system in place or very long extensive Time Locks , Both of which LN Devs don't want.

https://www.reddit.com/r/Bitcoin/comments/5eqm2b/can_ln_work_without_segwit/?st=izzovrzk&sh=b2fe8b0a

In Short , without Segwit any version of LN is going to be crap.

Hehe - yes and:  Just in case SW would be the better long term solution , nobody is really able to grasp it fully AND is able to convince crowds of the potential or things are fractioned / censored endless by different forum policies. We only see stupid fan boy chilling here - that's it. Sorry - just in case...

Aside from the fact Segwit lets LN steal tranaction fees from the miners and will bankrupt them.   :P
Which is why the miners will never vote segwit in.
What kind of mallet do I need to use to get that part to register with you.

https://www.thorhammer.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/r/a/rawhide_mallet_3.jpg


 8)

So what secures the LN network then?

Description : From Bitcoin Wiki.  
Lightning Network is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels.Dec 22, 2016

Segwit supporters say :
It relies on the underlying blockchain, be it Bitcoin’s or otherwise, for its security.
In the case of Bitcoin, it uses the underlying proof-of-work algorithm that secures the entire network to secure

But I will tell you the truth, LN Security Relies only on : proposed implementation of Hashed Timelock Contracts (HTLCs)
Time Locks are what you are relying on for Security in LN.

Examples: When the Time Locks expire your BTC can be stolen

Little tidbit no one likes to mention,   
LN Funds can be counterfeit like so.


 8)

dynamics has been tested actually..
though 1mb was the limit (in consensus.h).. much like some dynamics propose to move this to 16mb(in consensus.h)

pools have been dynamically moving their preferential block sizes since 2009.. (in policy.h) 2013 was below 500kb in 2015 it was below 750kb

so much like the many dynamic block proposals that want to elevate (in consensus.h) to 4mb, 8mb, 16mb, 32mb whatever.. there is and always has been a second limit that is dynamically moved below this(in policy.h)...

some proposals want the policy.h to have a bigger usefulness for the nodes. where the nodes flag to allow or not allow pools to go beyond X policy.h maxblocksize

good example of a previous event:
just imagine the headache if we stayed at 500kb blocks when Sipa done the leveldb bug event..
as thats the reality of the debate today. the same as the "do we go above 500kb in policy.h in 2013 eventhough consensus.h was 1mb"

p.s
my node and many other nodes have a consensus.h of 8mb right now and my node in particular has a policy.h limit of 1mb (and a few tweaks to validation) .. and im not having any problems

so you're saying the basic idea of emergent consensus that the core devs are pretending to be so freaked out about and claiming is so 'radically different'  has actually been done already...

Now I know BU is fo' reels YO! :D

This is the general behaviour of a soft fork: if a majority of miners adopts a soft fork, as a minority miner, you have no choice but to follow, or become insignificant.

Remember the definition of a soft fork: a soft fork is a protocol change, such that all what happens under the new protocol seems still valid under the old protocol, but on the other hand, what used to be valid under the old protocol isn't necessarily valid under the new one.

For instance, a typical soft fork it to black list addresses or to turn back former transactions (what is supposed not to be done, but it can, with a soft fork).  The old protocol allows these addresses to transact ; the new protocol doesn't.  Any new block that contains these forbidden transactions, will be considered valid by the old protocol, but invalid by the new one.  As such, if you are an old-protocol miner, and you make such blocks, it will be orphaned by all new protocol miners.  If they have the majority hash power, it will ALWAYS end up being orphaned.  On the other hand, old protocol miners will build upon new protocol blocks without problems.  They will not orphan new protocol blocks.  This makes that old protocol miners will always end up losing in majority acceptance of a soft fork.  A soft fork accepted by a majority IMPOSES ITSELF upon the rest.

This is totally different with a hard fork.  With a hard fork, new protocol blocks are considered not valid by the old protocol.  As such, if a fraction of the miners applies it, it will make a new chain, on which old protocol miners will never build.   The old protocol miners will continue building the old protocol block chain and will not suffer from the forked chain that the new protocol chain miners are now building.   Even 10%-90% or 90%-10% splits, nobody is FORCED to follow another protocol than what he wishes.  The chain that is being mined is always mined with full consensus, but the price to pay is that there are now two chains (which is normal, there are two non-agreeing consensus groups).  With a hard fork, nothing is imposed upon nobody.  With a soft fork, the majority imposes its will on the minority.

emergent consensus  (BU specific proposal of dynamics) has not been around since day one because BU hasnt been around since day one. then again core hasnt been around since 2009 either. (it was satoshi-qt prior to 2013)

but the whole thing about "excessive blocks"(BU specific proposal) is about making policy.h more important as the lower threshold and the "FLAGGER", while making it more automatically moveable.. rather than manually movable.

in the past 2013 sipa and core devs had to manually move the policy.h and so did pools.. though nodes were not really using policy.h as the node validation of block rule. pools were reliant on it.

infact early clients had 3 layers
protocol =32mb
consensus=1mb
policy <500kb
in the early days

what your quoting of my quote of a quote.. is:
1. breaking the "backward compatible" promise - yea i laughed reading they will literally want to ban blocks because they are not segwit branded even if the data was valid

2. causes a split in the network. yep i laughed that even going soft can cause a bilateral split. breaking the promise that going soft avoids such drama

So chilled with laudbankbraking words:

BU is much more Satoshi consensus like than anything else (= hacked agenda stuff ) we ve seen before?

 ;D

using gmaxwells words(not verbatim)
'BU is just a core 0.12 copy and paste job with a few minimal changes...'

well thats just proof that offering more capacity doesnt require a total game changing re-write of the entire thing, doesnt require "upstream filters" doesnt require new keys, doesnt require users moving funds to new keys just to see a feature, doesnt require intentionally banning nodes.

 

Here is one idea of scalability and transaction rate. It's quite old:

https://bitcointalk.org/index.php?topic=532.msg6306#msg6306

For it to work though, I don't think we can allow blockchains demand to exceed capacity, or for mempools to forget transactions for bitcoin service providers, or for nodes to be selective on the transactions they relay.

many dynamic blocks are envisioning including a 'speedtest' algo that tests their effectiveness to notice a new block download it, validate it and relay it out and set a score of start to end.
then use that to help flag the upper limit. they will accept which becomes consensus.h
where by they then have the lower limit policy.h has the prefered size as acceptable safety which can automaticaly grow at need BELOW the ultimate limit

this using the network consensus by x% flagging big no no to Xmb pools wont then make Xmb. thus not killing off nodes. and where nodes abilities as technology and telecommunications improve over the years allows the network t grow at an acceptable natural and progressive amount

(EG raspberryPi3 even behind the china firewall can handle 8mb blocks.. so a 8mb consensus.h and a 2mb policy.h to begin with which can increase naturally upto 8mb without having to manually do anything)
meaning pools would then go from 1mb.. and try 1.001mb to test the water and increment to say 1.99mb before worrying about orphans. and then the automated moving of the policy.h can occur. all while blocks are way below 8mb

do not be fooled by the "visa by midnight" "gigabyte by midnight" "servers by midnight" rhetoric that blockstreamers are spewing out when they exaggerate satoshis words to fit a fake narative that bitcoin needs to commercialise and centralise to survive

How would BU prevent malicious actors gaming the system, by running lots of nodes with restrictive settings? It would be a node race trying to set the consensus.

your talking about the same threat as what could have happened over the last 8 years by sybil attacking the network with lots of 500kb limit nodes

You mean by compiling a node with a lower block size limit and starting them all over the network?

you brought up the question of 'malicious actors gaming the system, by running lots of nodes with restrictive settings?'
so im just assuming you mean sybil attack.. and assuming you mean restrictive settings.. where by i gave an example of 500kb..

which is just as likely to happen even now or at anytime in the past it was as likely to have happened.

..
malicious actors gaming the system, by running lots of nodes with restrictive settings is no more or less a threat no different than the last 8 years.
there are many ways to mitigate these threats. EG recognising a jump in node count of nodes using things like amazon servers. and not including them in the tally. that way REAL decentralised nodes decide what the settings are, by simply not caring about amazon server capabilities.

that way the network sticks to what rational/true nodes are ok with

..
most sybil attacks are where people run LITE nodes(not full nodes) but tweak the useragent to look like its a full node to then spam out bad requests.

a simple way to know if a node is a full node could be:
take 3 numbers from 1to 450000...

say 234567, 321234, 432111(randomly chosen at each handshake)
my node could send that. and want a reply. EG the other node has to grab the block hashes of those 3 block through its own blockchain.. sha256 them together and send me the result. which if correct they get whitelisted
(imagine it like a 'are you human' captcha 'select the image of a roadsign....... but an 'are you fullnode' sha the hashes of these 3 blocks' )

it could go one step further.. by asking for tx number 27(randomly chosen at each handshake) of those blocks to sha together the TXID's

most sybil nodes malicious attackers wont shell out $$$ buying thousands of amazon accounts with 100gb data allowance each
so they wont have the blockdata to reply.

however real nodes will have the data. so its as an example just one way to check nodes are actually full nodes.

An idea worth considering.

Franky is correct.

Basically, sybil attacks are thwarted in Bitcoin because of Proof of Work.
Honest nodes need to control a majority of the hashing power.  That's never changed
and won't change under BU.

Somehow i'm under the impression that if core would have suggested the changes that come with BU, nobody would discuss them and we would have it up and running already.

Has anyone heard anything about a plan b on how core is going to address the blocksize problem in case SegWit is going to fail / not activated?

yep seems blockstreams next plans are wait for it..
soft(pool) BILATERAL SPLIT (bip9 allows this if u didnt know already)
hard(node and pool) BILATERAL SPLIT (new UASF does this. although the buzzword is meant to make it sound easier to stroke the sheep to sleep by pretending its a "soft" fix)

silly thing is they are really desperate to avoid hard(node and pool) consensus. which the community want so that other features can be added to and then just have one big activation event of everything the entire community want in one go)

but they are willing to do anything to get segwit activated without playing at the same level. even though segwit wont do as promised in any shape or form.(hard,soft / consensus,bilateral)  it just wont do what is promised.

its not segwit 'activation' that fixes anything.
its having everyones transactions only using segwit keys that fix the issues they promised, which will never happen.
malicious people will just stick to native keys. its that simple.
but blockstream have yet to come to that realisation as they have not done enough scenario tests. they have only done 'does it break' tests.. not any real 'does it fix' tests.

funny part is they went soft because of the fake rhetoric of hard consensus leads to a split.
but now willing to do a hard bilateral split to avoid hard consensus... (facepalm)

they are getting desperate.

they are doing all they can to avoid doing something the whole network can agree on. but then try pointing the finger in the other direction while they do the exact things they falsely accuse others of doing.

it has become totally ridiculous

Guys, I'm not legendary unlike most of you in this thread, and I haven't got as much experience with bitcoin as you but I've just got shocked with this BU and SW things earlyer this week, and I'd like to ask for your help to clarify some things.
Before last weekend  I was usually reading the forum and posting things about my ideas in connection with the future of bitcoin and banking industry, etc, At the end of last week I was waiting for a smaller amount of BTC. While I was waiting, I have realized that my little amount was not confirmed for 24 hours or so (0 confirmation). I was lucky and have used an accelerator at 0:01 AM, and this helped my transaction to get confirmed in the morning, at last.
I started to search for the forum about the possible reasons of this delay, and as I was digging deeper and deeper inside the threads, I just found the problem of the full mempool and the pricy confirmations of the urgent transactions.
As I'm not an expert, please forgive me if I ask you questions like newbies, but I'm really curious now:
Does it really the case that some groups from China spams the network with transactions in order to raise the fees of urgent transactions?
As I understood, that blocks has limited capacity (1MB) to include transactions. The transaction that pays more fee gets priorized (and there's no problem with this).
I saw that there are different solutions to raise the capacity of the blocks, but there's no consensus about the preferred way forward.
My question is:
If we find a solution somehow that fits for everyone in the system, and can raise the block limit, would this solve the problem of spamming the network?
E.g.: if we raise the limit to X MB, what is the guarantee that chinese groups won't fill that X MB capacity too, in order to prevent the fees from falling back to normal?
Before last weekend, I was really positive about the future of bitcoin, and now I'm really worried. Thanks for your help in advance!

You are honestly going to get different answers to this depending on who you ask.

Short answer: the network has reached capacity and must be increased in one form or another.
There's no guarantee against DOS/spam attacks in the future but generally, if the capacity
is several times bigger than the average load, it shouldn't represent too much of an issue
like it currently is.

I can't tell you if the spam is coming from China and how much spam there really is as it's easy to say that there are spam attacks, but i feel they are smaller then people think. Even with the current block size spammers could double their attacks to get even higher fees. But for some reason they don't do it. Maybe it is because it cost quite a bit. With a bigger block size it would cost them even more to keep spam as a problem to the rest of us.
Let us assume one block (1MB) consists of 10% spam (0,1MB) and . If they would double their effort to 0,2MB then we would see higher fees for sure. But if we have a block size of 2MB (however we achieved that) then the same amount of spam (0,1MB) would only be 5% and doubling would mean 10% (0,2MB). This is the same as at our starting position, but it would be a smaller problem, because this would leave us with 1,8MB non spam. So still more than enough for normal transactions. It would be very expensive to spam in a significant way. So this would give us some time until we would need the next increase in block size.

I think it won't happen.  Immutability and consensus can only be reached over status quo.

As I said elsewhere, the valuable commodity will not be the coins any more, but the room on the chain.

All that the BTU coin folks require is 51%. After all, they are entirely convinced that having 51% hash rate equals to being Bitcoin, which is on a level of absurdity not seen in a long time. Do you think that it is not possible for them to reach this number?

Then they will do a genuine hard fork and two coins.  But in order to REALLY do so, that means, when they will start producing *incompatible blocks* and mine on one another, they have to realize that they will make an altcoin, losing bitcoin's first mover value proposition, which is essentially the only thing that keeps it number one for the moment.   So I wonder whether they will really do that.  In any case, if they do, there will be two bitcoin chains, two coins.

ETH/ETC all over.

I think it would be a "good thing", because then the market can choose.  But I wonder whether they will dare to do so.
Bitcoin's first mover advantage is still too valuable in my opinion.    It would be great if bitcoin could hard fork into two coins.  But I don't think it will.
They might, by total ignorance of the system, thinking that 51% is imposing its will.  But with a hard fork, that is NOT the case, as the two chains are incompatible.  Non-BU miners will reject their "longest chain" as simply invalid, and build on the valid chain with smaller blocks.  That's how the two prongs of the fork will separate.  I have a hard time thinking that this would happen by ignorance.

Indeed. It will be a genuine hard fork / split, which would split off BU into their own altcoin. Something nice I found on reddit:

Similarly, you somehow attain 51% hashrate and split at one point (changing some rules along the way). Is your coin now Bitcoin? Whoever answers this question with 'yes' should visit a psychiatrist. ::)

Agreed. Well, now we know who is actively trying to harm that.

Indeed. It will be a genuine hard fork / split, which would split off BU into their own altcoin. Something nice I found on reddit:

Similarly, you somehow attain 51% hashrate and split at one point (changing some rules along the way). Is your coin now Bitcoin? Whoever answers this question with 'yes' should visit a psychiatrist. ::)
[/quote]

People don't seem to understand the fundamentals of crypto !

If you *remove the 21M coin limit* your chain is NOT COMPATIBLE with bitcoin, so of course it will not be bitcoin.  You have invalid blocks according to bitcoin's protocol !  You have simply produced an altcoin that is not recognized by the bitcoin protocol.

However, if you DON'T remove the 21M coin limit, and you start with Satoshi's genesis block, and you achieve a higher total PoW in the chain than the "real" bitcoin, then YES, you have taken over bitcoin.  That is a (very heavy) version of a successful 51% attack.


Nobody is "trying to harm" anything.  Consensus mechanism, nothing else.

Miners pay millions only for energy already (how much is your investment?) and miners (sadly...) might be more centralized as the rest of our community - they will come up with enough % of hash power and nodes if needed ( costs less than 100$) if time is ready.

We can dispute forever and try to split our community - it does not help, no it rather harms. Sit back and watch or spend some millions.

What about removing the *1 MB block size limit*? :D

I don't think you are informed on the background of these actors nor their motivations.

Irrelevant. This just adds a sybil variant to the existing hashrate attack.

Then tell the BU folk to stop trying to harm Bitcoin. ::)

look at lauda.. lol

1. BU does not cause bilateral fork. LEARN CONSENSUS
2. core want a bilateral split. they are begging for BU to split, but then pretend its "harming the network" if BU did split (hypocrits)
3. core want the split but want to play the victim card
4. BU, XT, classic, bitcoinj and the others DO NOT want a bilateral split. and if you READ THE CODE you will see its USING CONSENSUS to keep things together as one network
5. to create a bilateral fork nodes have to INTENTIONALLY BAN communications from each other to prevent orphans (bitcoins natural and USEFUL safety mechanism)


lauda please please please.
wake up. have some coffee then use the energy you have to suck up to gmaxwell, and use it to LEARN CONSENSUS

Yes it does cause a split. You are mistaken.

Of course, to get the altcoin away from Bitcoin.

Nonsense.

No.

Depends whether they've altered parameters or not.

Sure. Only if you stop taking money from your employer. ::)

READ THE DAMN CODE. PROVE IT

its not an altcoin until blockstream split away.. because the rest of the community wont do it so blockstream will have to if thats blockstreams intention to get 100% control with no one else on the network but blockstream making the decisions.

BU, bitcoinj, xt, classic and a dozen others dont want to be kings. they want consensus of no kings and using CONSENSUS.. learn consensus

your own words are the "victim card' - pretending its BU harming the network.
when infact its blockstream wanting the split!!! wake up!!
BU, bitcoinj, xt, classic and a dozen others dont want to be kings. they want consensus of no kings and using CONSENSUS.. learn consensus


im my own boss. i dont need to be paid to be awake

Do tell me what happens when a BU blocked (not just signaling) is mined with e.g. 1.5 MB block size.

BTU is an altcoin.

Because it is. You should read the posts from 'dinofelis'; maybe you will learn something.

No.

Highly doubtful at best.

I do - I speak to Bitcoin United.

This monster cluster fuck we are in right now has something good.

We now have more than one solution - it's a luxury !

The reason is clear, one group has failed to deliver the no-brainer solution that fits all.

I feel very sorry for some 'core' Core devs since I ve spoken with one just some days ago for about 1 hour face to face trying to understand some of the issues - as unbiased as I could - politics and own agendas are bad....

Most ve done and still do a great job keeping things just up and running (most forget about this !) - but sorting out the right features for the next releases is hardest in terms of scaling and long term future and 'we' all try to deliver best, but just are dammed to 'fail' sometime - that's our complex life.


Admitting such failures is one of the strongest personal features human can have. Only with this we can do the next step forward  and still we don't know for sure it the next one is correct.



 

if consensus is not reached.. its orphaned. end of.. in the trash in 3 seconds. no drama no fuss

want proof of a block over 1mb

He is mistaken, but for different reasons. BU is a unilateral split. If, after BU pulls the trigger on their hard fork, the Core chain ever overtakes the BU chain, all BU coins will be permanently destroyed and all transactions involving them will be forever invalid. Mass panic will ensue and their altcoin will be worthless. That's why Core devs are begging BU to make their fork bilateral, but they won't listen (or they pretend not to listen because they don't have the competence to implement a bilateral fork).

Could you pls elaborate on sth I ve just seen sw else that BU (and > 1MB blocks) could be run side to side / compatible  together with a very ancient Satoshi version 0.3 or so, just with no block size issues at all ?

This would show to all how close BU is to initial Bitcoin?

if BU pulls the trigger.. it would do it with majority NODE (over50%) and majority hash(over 50%)
it wont trigger without consensus.

also all that occurs is a orphan  which will inevitably and naturally find a single chain.
at a small majority (say 51-60%) just means clusterf*ck of orphan drama.
at a high majority (say 80-95%) just means less orphan drama
at superhigh majority (say 95%) just meand bearable amount of orphan drama, slightly above what happens daily anyway

just taking longer(more orphans) with lower amount of majority to get a single reliable chain

the only way to get the 2 chains to independantly survive is to intentionally ban communications with the opposition. which is what happened in ethereum

oh and emphasis on majority.. which also bursts your bubble of core overtaking lol (learn consensus please)

Well, then you ALSO create an (incompatible) alt coin.  That's what a hard fork is: to create an alt coin.  


But that is part of the "consensus mechanism".  Having different motives, and wanting to "pull the blanket to your side" is exactly what the distributed consensus mechanism is about.  The impossibility of collusion over "pulling the blanket to your side" is exactly the origin of the immutability.  As one cannot agree on WHICH SCAM to propagate, no scam is propagated: immutability.

Distributed TRUSTLESS consensus is the putting together of sufficiently many and diverse scammers, that they cannot agree upon a single scam.  That is the essence of distributed consensus, providing you with immutability.

You are seriously confused about this aspect.  There is no "majority hash rate consensus" between INCOMPATIBLE CHAINS.  The only thing you do with your 51% hash rate is to produce INVALID BLOCKS wrt the original protocol.  So this PoW doesn't matter, the blocks are invalid.  If you produce 1.5 MB blocks with a PoW that is more than 10 times all the PoW that ever went into bitcoin, then these blocks doesn't count because they are simply INVALID.  The old protocol simply rejects them (in the same way as if they were containing wrong signatures in the transactions).  The only valid blocks (wrt the old protocol) are those, mined with the 49% hash rate of the miners sticking to the old protocol.

But the new protocol can continue building on its own chain with bigger blocks.  

Of course, as long as BU accepts also old-protocol blocks, they need 51% of the hash rate, or the old chain (which is VALID under the new BU protocol if they don't protect themselves) will take over.  In fact, in this case, you can see the old protocol as a soft fork from the BU protocol, which can IMPOSE its will when it is majority.  In order to avoid that, BU should make the old protocol invalid too, so that ONLY BU blocks are compatible with BU.  Maybe they could flip a little-endian/big-endian convention somewhere, so that both are fully incompatible.  Otherwise, they risk at any moment to be killed by the "soft fork" of the old protocol.

Non BU blocks are still 100% compatible with BU so if BU doesn't have more than 50% of hash power, the fork will fail untless BU miners intentionally filter the non BU nodes. The only way for a fork to be successful is if the BU miners mine a block > 1 MB and have 51%+ of the hash power. Personally I'll wait until 18 blocks longer before I really consider the fork successful.

nope.
your over using the umbrella term hard fork but not understanding the categories within the hard vs soft.
save rewriting to repeat myself

if only blockstream lovers stopped reading the doomsday scripts on reddit and the fake promise sales pitches.. and instead learned bitcoin especially consensus and bitcoins natural safeguard of consensus via orphans.. they would actually help themselves more and start giving real support to the community. rather than just kissing blockstream ass.

note to all blockstream loving doomsdayers
learn consensus

Yes, you are right (see the edit of my previous post).  This "backward compatibility" of BU with respect to the standard protocol makes that the standard protocol is a soft fork of BU.  Then they expose themselves AT ANY MOMENT to be orphaned, even 6 months later, if ever the BU fork falls beneat 51% hash rate.  Then you will get the bitcoin chain orphaned 6 months behind, because from the first >1MB onwards, the soft fork is not compatible any more, and this will be the last valid block on the chain.  Major clusterfuck !

The only safe way of making the BU hard fork, is by making it incompatible with the old protocol.  If they don't do this, and they "pull the trigger", this will be a major disaster on the chain.

YOUR FORGETTING NODES aswell as POOL
learn real consensus

also your forgetting without banning communications. the minority see the blockheight. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
endlessly.

BU wont ban the other community nodes.. only blockstream would ban the community nodes.
and that would only happen if blockstream were minority. because the community wont trigger unless they had majority.

and thats what blockstream fears.. losing their control where by the dozen other independant node brands continue.

remember and learn consensus

FTFY

If a fork appears, I suspect we'll quickly see a new version of core with support for bigger blocks because they still want SegWit. So a BU fork may result in an actual compromise.

You are simply wrong on this.

A hard fork without a strong consensus ALWAYS leads to two coins.

A soft fork with a majority consensus amongst miners ALWAYS imposes its rules and one chain emerges.

A hard fork is defined as a modification in the protocol, so that new blocks under the hard fork are not valid under the old protocol.  You still have two cases: the hard fork can be backward compatible, so that blocks under the old protocol are still valid under the new protocol (call it a backward compatible hard fork), or you can have a genuine hard fork that is entirely incompatible.

A soft fork is defined as a modification in the protocol, so that new blocks under the soft fork are still valid under the old protocol, but that blocks under the old protocol aren't valid any more under the new protocol.

Case of a soft fork:
- if a minority of miners adopts it, not really an effect.
- if a majority of miners adopts it, it is IMPOSED UPON the others.  A single chain is always the result.  The user has no choice.

Case of a full hard fork:
- from the moment a non-negligible fraction of the miners adopts it, TWO COINS emerge.  The market will split the market cap over the two coins, and miners will follow that ratio.  It is possible that the market entirely kills one of the coins, or that essentially ALL miners adopt it: ---> consensus is preserved.  ONLY IN THIS CASE, a single chain emerges (the "alt coin" in case of full consensus).

Case of a backward compatible hard fork:
the old protocol can be seen as a soft fork from the hard fork.  
- As such, as long as the old protocol remains a majority, this "soft fork" remains imposed, the hard fork cannot happen.  
- if the hard fork is majority, it can split the chain into two coins, like a full hard fork.
However, if the hard fork loses majority, the second chain becomes a major orphan, and is taken over by the old protocol chain (can be six months later)  --> super cluster fuck.

Non-mining-related nodes don't matter.   Transactions will reach mining nodes/pools.  Non-mining nodes are only interesting for its owner, to see the block chain for himself, and verify its validity without having to trust another full node.  But full nodes that do not relate to mining don't matter in the consensus mechanism.

Everybody can fire up 100 000 nodes on amazon if he/she wants to.

What does matter, are users.  They 'vote with their money' and determine market cap.

you have been sold alot of BS
1. exchanges are the nodes. if they orphan block X.. your TX in that block doesnt exist = you cant spend because they dont see it
2. if a friend is using a node and you pay that friend. if they orphan block X.. your tx in that block doesnt exist  = you cant spend because they dont see it

with each node calling out the blockheight. they all grab data from the highest block height. if that blockheight is blocks of rules that dont match
then they orphan those blocks. and end up unsynced.

the only way to sync is either change your rules to rejoin the majority.
or.
BAN the majority to not see the block height to not be endlessly clusterfu*ked to then start building on a minority that you can accept.
if you dont ban. your minority is not treated as a valid chain due to it not having the height.

its a security feature.
otherwise someone could copy the blockchain. kill off say 2 years of blockheight and then just build ontop of it.(at a healthier difficulty) and then build their own chain
but that requires not communicating with the rest of the network by banning the nodes following the highest blockheight, so that the blockheight mechanism doesnt kill off the minority due to the minority height reject mechanism.

like i said many times it involves intentionally banning nodes to not see a bigger height. otherwise orphan games begin fighting over the rules

Such a mass banning of the nodes would effectively be creating a private network, would it not? (Although coordination levels would probably have to be 100% to prevent leaking between networks through a node)

You are talking about USERS, not "nodes".   Again, we have to distinguish several cases.  Suppose that we have a full hard fork (not backwards compatible).  If my friend, or my exchange, is using a "node only compatible with variant X", then it simply means they are only accepting COIN X.  If I try to pay them with coin Y, it won't work of course.  That's like as if I tried to pay a bitcoin user with Ethereum.  So the full hard fork case is easy: we're simply talking about different COINS.

Now, suppose that we talk about a soft fork.  If the soft fork has a majority amongst miners, that soft fork is simply imposed upon all miners.  Simply because every non-soft forked miner will always produce orphaned blocks, because they are considered invalid by the majority of miners.  So his only chance of getting accepted blocks on the longest chain, is also to apply the soft fork conditions.  The users nor the nodes have anything to say about it, because there's only ONE CHAIN.  They accept it, or they come to a grinding halt.  A soft fork with a majority of miners is IMPOSED upon everybody: the minority miners, the users, and the nodes.  Nodes with both protocols will accept the chain, and it *doesn't matter* what protocol they run.

Now, suppose that the soft fork is in a minority amongst miners.  That means that the majority of miners will regularly put blocks on the chain that are not accepted by the soft fork, but this will be *the only chain* that is available.  If your node is running soft-forked software, then it will simply REJECT the sole chain that exists.  But no acceptable chain will be around.  Because majority-non-soft-forked miners will still add blocks to the longest chain, and the "pure soft fork chain" will not exist.  So your node COMES TO A GRINDING HALT if it is soft-forked.  

The case of the backward-compatible hard fork looks more involved.  As long as the hard fork has a majority of mining hash rate, BOTH COINS exist.  If you want to pay a friend in "hard forked coin", you have to send "hard forked coin".  It is ANOTHER coin (an alt coin), and of course if you try to send him your original coin, it will not work.  Idem for an exchange.  A hard fork that remains a majority is similar to a full hard fork: TWO COINS exist now with separate block chains, transactions, wallets and everything.  If an exchange, a user, .... only decides to use ONE of the coins, then you have to use THAT COIN to pay him.

It becomes a major cluster fuck if the hard fork that had majority, loses this majority (determined by MARKET CAP, and miners that will follow to optimize their block rewards).  After a while, the old chain will become the longest one, and because the hard fork is backward compatible, the former hard forked chain STOPS and is orphaned.  Every wallet there is then simply LOST, and all transactions on that chain are REVERSED.

Which is impossible.  Valid transactions on one network will ALWAYS end up reaching the miners on the other network if these transactions are also valid there.  We saw this with ETC/ETH.  Miners on the other network have all incentive to process these transactions to collect the fees in *their* coin.  In the end, they go and READ THE OTHER public BLOCK CHAIN to get the transactions on their chain.

dinofelis

you cant have 2 chains that inter communicate. the nodes would orphan one chain off and the network then follows the chain with the highest height

they would need to ban each other. meaning you get to spend coins on Y while holding onto coins on X, without having to worry about spending coins on Y being broadcast to also spend it on X

thats why eth and etc dont co mingle.

---

for instance clams is a clone of BTC.. but ever since they banned communication with btc to create the alt, the transactions i do on btc do not end up in a block on clams.(even if the tx data is the same and the UTXO is the same) they dont broadcast between each other because they intentionally banned communication with btc.

if clams was to inter connect to see the tx's being relayed. then the clusterf*ck of orphans would occur because thats a consensus safety mechanism. leading to there being just one chain and a clusterf*ck of orphans fighting over who can or cannot get to be the next block ontop of the blockheight.
where by the pools and nodes are not building ontop of height say 400k if they see that there is a 460k height available they would build ontop of the heighest height and the network will accept the highest height

this is why even in segwits softfork, segwit will intentionally ban opposing pools and nodes to avoid the orphan drama and chance of segwit blocks being orphaned out. maning blockstream cause an intentional split. not simply by having hash. but BANNONG BLOCKS AND NODES that are opposing them

it isnt just a simple 'trigger date/% achieved' and thats it.
there is more to it then that

You are entirely confused over this.  With a full hard fork, you have 2 chains, 2 coins.  Call them X and Y.  A node running protocol X, will recognize chain X as valid, and will consider chain Y as invalid.  So this node will only accept chain X, and its wallet will show you your holdings in coin X.  A node running protocol Y will recognize chain Y as valid, and will consider chain X as invalid.  This node will only accept chain Y, and its wallet will shwo you your holdings of coin Y.

Whether one chain has more PoW or not doesn't matter to a node for which that chain is invalid.


They don't co-mingle, NOT BECAUSE THEY BAN EACH OTHER.  But because transactions of ETH are not valid on the ETC chain and vice versa.

There WAS a problem when people transacted on the ETC chain, and generated also a valid transaction on the ETH chain, because they used pre-fork UTXO.  This transaction got included in the ETH chain too, and these people had against their wishes, also transacted their ETH holdings.  With ETH this could be solved with a smart contract.  Bitcoin can't do that.  But what you can do, is to obtain some freshly mined coins on one chain, or on the other, and mix them in your transactions.  Then, these coins exist only on one chain, and this transaction is only valid on one chain.  Mere mortals can't do this, but exchanges can.  They only need to make a transaction with some dust included from one after-split coinbase or the other to split the pre-fork coin into an X-coin and a Y-coin.


That is ridiculous.  I don't know clams.  But if clams wanted, it could install a bitcoin full node, READ THE BITCOIN BLOCK CHAIN, and include all transactions on the chain in its chain, because the signatures are, according to your saying, correct.


This is again, ridiculous as a safety technique.  Of course clams can see these transactions, they are on a fucking public block chain !

No, this is a normal SOFT fork mechanism.  OF COURSE it 'bans' non-soft-fork blocks: they are INVALID according to the softfork protocol.  That's proper to a soft fork.

A soft fork never makes two chains.  It simply orphans the prongs of the minority if it has a majority.  This has nothing to do with nodes and so on, only with miners.  If a majority of miners applies a soft fork (no matter what soft fork, just ANY extra condition on top of the normal protocol) then minority miners will always get orphaned, until they join the majority, and no matter what node software you run, you will only get the soft fork valid chain.

For instance, if the soft fork simply consists in "including a transaction from Joe's address is considered invalid", and if a majority of miners applies this condition, then the chain that EVERYBODY will see, will never contain a transaction from Joe.  Those minority miners that do accept Joe's transaction, will make blocks that get orphaned by the majority.  So minority miners can chose not to make blocks that contain Joe's transaction (and hence, "apply the soft fork") and be included, or systematically get orphaned.  So in the end, only a chain without Joe's transactions will be available.  Whether or not people run nodes with or without this restriction, doesn't matter.  They will only get a chain without Joe's transaction.

Segwit is the same.

You have misunderstood the question. I was implying what happens once they have e.g. majority hashrate, which they think alone is sufficient enough to define Bitcoin.

Oh, that's for the explanation. I just haven't thought about it that much to come to such a realization.

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?

---

Update: I completely forgot about hashPrev. I need some sleep.

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).

For BU nodes:  2 chains: A1 - B1 - B2  OR: A1 - A2.  First chain has more PoW ("is longer"), so winning chain: A1 - B1 - B2

for old nodes: A1 - A2 (other blocks are invalid)

As BU *has more hash rate* this will continue.

At no point, an "A" miner will build upon the B chain (invalid blocks), and at every point, the BU nodes will see more PoW in the B chain.

But, but, but, drama and catastrophy.  If BU now becomes minority hash.

We have:

A1 - B1 - B2 - B3 - B4 ..... B250

A1 - A2 ..... - A100

For a while, everything goes still well.  But A having more hash rate, it will grow faster.

So after a while, we have:

A1 - B1 - B2 ..... B500
A1 - A2 ..... A-501

BOING!!!

Now, for the BU miners, the A chain is the longest.  They will add their new block to the A chain:

A1 - ...   A-501 - B502

But for the (majority hash rate) A miners, this is an invalid block.

They will also mine an A502 block.  
And then an A503 one on top of that.  B502 gets orphaned.

Next, the BU miners still find:

A1.... A501-A502-A503 a valid and longest chain.

They will add B504 on top of it...

But the A miners will outcompete them with A504 and A505.  B504 gets orphaned....


And the B chain is dead.
Everything that happened on the B chain is as if it never happened.

Unless the B miners decide to implement something that makes it a bilateral split.  A soft fork on B is thinkable, that A doesn't have.

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

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 ?  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 ?

Of course not.  B1 and B2 are simply considered invalid blocks by old nodes.   The old nodes will all agree that they are at height 460001.  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.  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.

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


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.

invalid to A which leaves A stuck (B accepts them so B continues)


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

now your getting it
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

Of course, because the A chain is NOT ANY LONGER.  So A "being stuck at 460001" is perfectly normal, it is the longest chain that is in agreement with A's protocol.


Of course.


Because that was the longest A chain up to that point.

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).

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.  B nodes consider this an orphaned block, and don't include it (and most probably don't propagate it either).


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 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.

How an Average Joe (like me) can avoid to get in touch with a B type of node? Does it depend on the wallet type I use or it depends on the physical location, if there is only B type nodes around me?
As far as I understood, now there are already nodes in the system, upgraded their software to be able to produce larger blocks (but not yet produced any, because they're waiting for being majority)
What can I do if I want to ensure the safety of my coins and transactions? Can I choose a wallet that only communicate only to old A nodes?
Or wallets are just put the transactions into the pool and the mining node selects the transactions they want to mine for the fee offered?
Is it possible to check if any of my earlier transaction's blocks have been mined by a node with 'upgraded' software? Just to be on the safe side, if chain forks...
Or, the software of the node doesn't matter as long as they produce only normal size blocks?
I'm all ears...

You are fin so far and if a fork occurs you'll have Bitcoins on both chains. Just make sure you have the private key or else they are not your coins anyway. Information will be everywhere if a fork happens and when you want to decide if you just want to be on one chain. Which chain this should be will be best answer then, since we will have more informations about stuff we have to anticipate/guess right now.

your getting it

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


only if A has banned B

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


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

A is only longest if A is all it sees... by banning B nodes



when it bans B nodes

I never said anything else.  Look at earlier posts.


You are seriously confused.  Non-valid blocks don't count.  The longest chain is the longest VALID chain.

I will try to explain it in a different way.  Suppose that there are not block, but numbers.  The old protocol accepts prime numbers.  The new protocol accepts uneven numbers.  So the new protocol is a backwards compatible hard fork of the old one.

We had previously.

.... - 13 - 17 - 19 - 23

when the hard fork gets activated.

Now, the new nodes produce 25 - 27, because these are uneven numbers.

The old nodes see:

 - 13 - 17 - 19 - 23 - 25 - 27, but they see that these last two blocks are invalid.

So the longest chain, for the old nodes, is still:

  - 13 - 17 - 19 - 23 STOP.  They regularly get a 25 and a 27, but as these are not prime numbers, they reject them.  As they should.  

However, the new nodes accept:

 - 13 - 17 - 19 - 23 - 25 - 27.  That's a different chain.

My analogy breaks down at the next step, because the "29" for one chain will not be the 29 for the other, as it contains the hash of the previous one with blocks which doesn't work with numbers.

For the A nodes, "25 and 27" are not "orphaned", or whatever, they are simply INVALID blocks, and the A miners will mine upon 23, the highest block in their chain, and will build a 29a,  while the new nodes will make a 29b, built upon 27, which is the highest valid block in THEIR chain.

When old nodes receive the 29b block, they will reject it, because it is not built upon a previously valid block (it is built upon 27, which was not a previously valid block), and when new nodes receive 29a, they will think it is an orphaned block built after 23, while they are already at 27 at that point, so they orphan it and don't include it.

So each node builds its own chain correctly.

old nodes will see: - 13 - 17 - 19 - 23 - 29a  (and reject 25, 27 and 29b as invalid)
new nodes will see - 13 - 17 - 19 - 23 - 25 - 27 - 29b  (and reject 29a as orphaned)


No banning is needed.  But banning may help avoid "noise on the line".  The connections between old nodes and new nodes are useless, add some noise, but are not harmful.

If, say, the split is 75% - 25% then if each node connects randomly to 8 other nodes, he'll have on average 6 B nodes and 2 A nodes.  An A node receives only noise from B nodes, and a B node receives only noise from A nodes.  So the only links that bring useful information, is between equally minded nodes.  But the other nodes are just seen as "confused" or "behind", sending only orphaned blocks, or sending only invalid blocks.

Anybody here that could provide the peace of code that is in dispute? I'm not that familiar with the Bitcoin code yet, but this might help to understand. And also the question goes along, if they are different in Core and BU.

We move to a different blockchain and have two competing coins which both can be considered Bitcoin, Bitcoin A is the BU fork while Bitcoin B is the familiar Bitcoin we had pre-fork.

On both assuming the transaction was not in the mempool and unconfirmed at that time of the fork you will have a balance on both A and B or in effect the coins are doubled and depending on if a Bitcoin exchange accepts A and B you can sell both sides of the coin or the one you believe will become the most utilized chain in the future.

Future disputes may result in code changes but probably not force another fork in the short-term as consolidation occurs around the new chain.

(Assuming a Bi-lateral fork, else .... stuff happens we don't want to discuss but sum up as Core ate it and all the history from fork on is null) Replaced with Core or the reverse with orphan blocks everywhere ...


Assuming that the BU fork moves sufficient users, demand may drop temporarily on the main chain as it moves to BU Hard Fork.

Some miners will also move and the ones remaining that operate may be the ones in favor of Segwit hence Segwit would be able to acquire consensus and a soft-fork would be approved by the remaining network unless sufficient factions still remain to not reach the soft-fork target.
Lightning activates later


3rd Scenario: Nothing happens for now.
4th Scenario: Alternative proposals that adjust the weight of each actor in Bitcoin gains support and becomes a new option.