The Barry Silbert segwit2x agreement with >80% miner support.

[classicsucks]

OK so Shillbert makes a last-ditch effort to save the Core team and Blockstream's $75 mil. He pretends that Core is snubbing him, even though he could have every single core dev present by sending one "mission-critical" email. The miners smell a rat, and agree to some stuff but not really exactly what anyone wants.

Aren't we assuming that 80% of the relevant people will run this crappy code? I'm waiting a few weeks for this latest spin cycle to finish...

[1715248883]

1715248883

[1715248883]

1715248883

[1715248883]

1715248883

[1715248883]

1715248883

[1715248883]

1715248883

[Carlton Banks]

4) The agreement has already failed:

lol. BarryCoin, #REKT at birth

[Searing]

1) A few companies, i.e. people in suits don't define Bitcoin.
2) The people who are stating that there should not be a block size limit at all are uneducated idiots.
3) "Consensus reached" articles are written by even bigger idiots.
4) The agreement has already failed:

My view...(not that I know what I'm talking about in this epic cluster) is that there will NEVER be an agreement
as long as they want a hard fork to increase block size.

Bitcoin Core Devs will just block this ...like BU blocked segregated witness

They COULD perhaps do a deal like litecoin that said seg witness is a done deal and a soft fork
in the future to increase block size .....but hell that might be stretching it..because even litecoin
said something to the effect hard fork or soft fork whichever is appropriate if I remember right

But a hard fork is dead in the water (again imho) because it is NOT backwards compatible with those
that do not upgrade and bitcoin core I think sees this as a huge cluster...thus their push for UASF.

Not saying any bitcoin dev of any flavor has the answer here...just saying for getting on the same page
it is not (again imho) gonna happen with bitcoin core as long as hard fork is mentioned as a solution.

[The One]

1) A few companies, i.e. people in suits don't define Bitcoin.
2) The people who are stating that there should not be a block size limit at all are uneducated idiots.
3) "Consensus reached" articles are written by even bigger idiots.
4) The agreement has already failed:

So basically all these people get together - agree on something - all have different agreements.

Perhaps they all should bring a translator next time.

Massive communication breakdown somewhere.

[hv_]

Matt is correct, his going wouldn't have helped anything.

Yeah, but he might be wrong in his position about HF...

[dinofelis]

But at least I'm happy that you consider block size just as well a hard economic parameter as inflation rate.   I think that the block size limit as an economic parameter, introducing scarcity of transaction room, was a stupid thing to do in bitcoin's design, but so is its inflation rate.  So, bitcoin being designed as a system with a scarce and finite number of coins, I don't see the problem with bitcoin as a system with a finite and scarce number of transactions per unit of time.  I have to say I think the economic model of both is stupid if the idea was to make a currency, but then, that's how bitcoin was designed, and I think that is the way it should live its life.  The economic design looks more like the one for "exclusive famous paintings" which are rare to come by, and difficult to transact, in other words, a kind of highly speculative and not  very liquid asset with high price that is rarely moved, and only to move big amounts of value (not a currency at all, but a "settlement layer for rich guys doing things where fiat cannot go").  

This is a typical error that people make. First of all, a block have nothing to do with economics. It is an accountancy thing. Double book-keeping with 2 columns; Expenditure and Income. In Bitcoin it is; Input and Output. The original blocksize was 32mb and the 1mb was temporary anti-spam measure.

I know that it was presented that way, and maybe it was even *intended* that way.   But a desirable outcome is not necessarily the actual outcome of a design.  If I make a rocket to go to the moon, and I put propellers on it, even if my intentions are to get to the moon, my rocket will never leave the atmosphere.  Arguing that propellers should bring me to the moon because that's why I put them on my rocket in the first place, is an erroneous form of reasoning that takes desired outcome as provable consequence.

If one puts a hard limit on something, you make it artificially scarce.  One has put an artificial limit on the number of bitcoins that are made.  Nothing technical would stop you from making more of them.  Changing the >>= into <<= in the calculation of the coinbase reward is all that is needed to have doublings instead of halvings every 210 000 blocks.  But one put halvings, to make bitcoins artificially scarce and hence expensive.

Whether this was the intention or not, one did the same with the number of transactions by limiting the amount of produced transaction room to 1 MB/10 minutes.  This could actually be a very smart move, because the scarcity of transaction room makes it expensive: the fees.  Given that sooner or later, the whole of bitcoin's PoW security must be paid by fees, it wouldn't be crazy to make fees expensive.

Why 1 MB and not 10 MB ?  That's similar to "why 21 million coins and not 210 million coins ?".  Arbitrary choice of scarcity.  But it *is* a scarcity parameter, and its price is the fee, like the number of bitcoins is scarce and its price is the market price of a coin.

A company does not limited its sales according to the double book-keeping size. Sales are limited by the goods/services they have on offer - economic. The original limit of 32mb was a good one and allows adoptions to grow naturally over a decade or more before reaching the limit. Thus there is plenty of time to solve the capacity/scaling issue before the limit is reached.

I agree with you on the idea that *if bitcoin were not to be scarce in transactions*, but it wasn't designed that way.  I also think that the uncapped value of bitcoin is wrong.  I think bitcoin's value should be regulated automatically (I already said how).  But no, people want scarce coins that can go moon.  Well, they  also have scarce transaction room that can go moon too.

Both of these are bad for a currency.  A currency should have fluid transactions, and should have stable value.  Bitcoin is designed to have speculative value by scarcity of coins, and is equally designed to have expensive transactions by scarcity of room.  The coin emission lowers, the transaction "emission" is constant.  Hell, it would even be funny if block SIZE halved also every 210 000 blocks !  Then the total block chain would have finite length and the last transaction would take place in some 10s of years when the block size drops under 1 KB, in the same way as the emission rate drops under 1 Satoshi.

Can't help it that it is designed that way, even if it was not intended that way.

[sturle]

I think their refusal to turn up reflects rather poorly on them, though I've no idea how much notice was given. It's starting to look a little like they're more interested in sneering than working towards something everyone's happy enough with.

Core developers were NOT invited.

LOL!  Is this going to be a new bug party, like "BU" and "Classic", with Trump-style "best" programmers and testing?  Haha!  Good lock convincing anyone to run it.  This is only an attempt to fire up more in-fighting and delays.  I hope they fork off quickly, crash and burn and we can forget about them.

[sturle]

Core developers were NOT invited.

According to this they were.



But I've no idea who or what to believe any more.

This can easily be verified as fake.  There is no trace of his email on the bitcoin-dev mailing list, where he will reach all bitcoin-developers.  Either he has been sending to a few people who he knew wouldn't be going to the conference, or he made it up.  The only natural address for an invitation like this, is the bitcoin-dev mailing list, where suggestions regarding improvements to bitcoin are discussed and reviewed.

[Lauda]

OK so Shillbert makes a last-ditch effort to save the Core team and Blockstream's $75 mil.

This has nothing to do with Core nor Blockstream. That is an attempt to turn Bitcoin from a consensus based system to a 'consensus-by-proxy'.

lol. BarryCoin, #REKT at birth

These attempts at centralization are really absurd.

My view...(not that I know what I'm talking about in this epic cluster) is that there will NEVER be an agreementas long as they want a hard fork to increase block size.
Bitcoin Core Devs will just block this ...like BU blocked segregated witness

No. You are very much mistaken. Almost all the Bitcoin Core developer are in favor of a block size increase (except Luke-jr and some others) when the time is right. They just favor Segwit right now and strongly believe that there is consensus behind it (and there is, among users).

So basically all these people get together - agree on something - all have different agreements. Perhaps they all should bring a translator next time. Massive communication breakdown somewhere.

Remember the analogy that was previously used:
Should passengers decide how to design and build the plane instead of the engineers? This agreement is a modification, where the wording 'passengers' is replaced by 'businessmen'.

This can easily be verified as fake.  There is no trace of his email on the bitcoin-dev mailing list, where he will reach all bitcoin-developers.  Either he has been sending to a few people who he knew wouldn't be going to the conference, or he made it up.  The only natural address for an invitation like this, is the bitcoin-dev mailing list, where suggestions regarding improvements to bitcoin are discussed and reviewed.

"Gmaxwell on "Frankensegwit" agreement: we were explicitly disinvited then reinvited then disinvited.": https://0bin.net/paste/catFu7J9BqL7zsFq#xByDHjK6HYhzmcXXMVgeBX8tYUB6+-9pb14RBxEJVF0

[Last of the V8s]

http://log.mkj.lt/trilema/20170524/#101 [05:06:59] · <mircea_popescu> that silbert schmuck is on his what, 5th "oh, i will change the world" hear him roar, only to be used as a cum rag ?

[05:07:29] · <mircea_popescu> i suppose if you're going to be an ustardian empire spearhead, it helps to have no shame and no memory.

http://qntra.net/2017/05/still-no-consensus-supporting-bitcoin-hardfork-barry-silbert-pretends-otherwise-to-his-peril/

Barry Silbert's (WOT:nonperson) "Digital Currency Group" announced in a medium post that yet another delusion of consensus arrived in the Bitcoin scaling debate with "A conference sponsored by the Ethereum, Dash, and Ripple scams produces an agreement on how to scale Bitcoin". The post outlined the reasons the conference attendees believe they get to make decisions in Bitcoin, with claims of support for the proposals by:
   ...
A selection of scam artists doing business as "companies" while lacking the charm necessary to fleece the elderly allege they will "provide technical and engineering support to test and support the upgrade software, as well as to assist companies with preparing for the upgrades". Noted names incapable of providing meaningful testing or support such as: the MLM BitClub Network, Ryan X. Charles' paywalled spam reader, and Gavin Assassinsen were offered as options for the forkcurious to seek support from.

[sturle]

These modifications don't seem like difficult to do in 4 months, right ?

Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.

Not really.  If you keep your old node running, you copy the the old fork, if sufficient miners go with the old fork to still make some blocks.  If you download the new node, you copy the new fork.  

And lose bitcoin.  How well do you think that will be welcomed by the greater community, and how much would you trust a currency whish did that?

You never lose bitcoins because you run a non-mining node.

This is wrong in so many ways, you obviously have no clue.

First of all I am running a mining node, but that's beside the point.

Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.

If you receive a transaction on your node, and it is confirmed, you will regard it as a good one.  The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently.  So you will lose coins, and can easily be scammed.

The only things that matter is what is recorded on the block chain(s).  Whether your local copy gets fucked up or not doesn't matter.  The only thing you can have as an accident, is that your old software makes a funny transaction that is nevertheless accepted in some way by the miners and put in a chain, but is in a way screwed up that you cannot use its outputs any more.

What?  No.

If my chain is corrupted the, my node will just re-download the blocks with failing hashes, and I will be back on the best valid chain I am on.  

But by running an old node, you never "lose bitcoins".  And if bitcoin forks in two chains, you have your former coins on both of them.

And as soon as you spend them, you may be victim to an attack where someone copy your transaction to the other chain, and receive your coins on both chains.  Unless double-spending protection is in place before the chain splits.  This was not the case with ethereum, and many lost their coins on one of the chains due to this vulnerability.  None of the bit-altcoins address this problem properly in their attempted chain splits, and this is why exchanges won't adopt them, even as altcoins.

If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already.  It doesn't, because people want bitcoin to be a secure store of value.

It doesn't, simply because of the mechanism of immutability, which, however, can break down if centralization occurs and there's a collusion of more than 50% of the consensus (= hash) power over a change.

> 50% of hashpower can only restrict activity by refusing to mine certain transactions.  They can not change the consensus.  If they produce invalid blocks, the hashpower is worthless.  Nodes will just throw their blocks away.

But at least I'm happy that you consider block size just as well a hard economic parameter as inflation rate.   I think that the block size limit as an economic parameter, introducing scarcity of transaction room, was a stupid thing to do in bitcoin's design, but so is its inflation rate.  So, bitcoin being designed as a system with a scarce and finite number of coins, I don't see the problem with bitcoin as a system with a finite and scarce number of transactions per unit of time.  I have to say I think the economic model of both is stupid if the idea was to make a currency, but then, that's how bitcoin was designed, and I think that is the way it should live its life.  The economic design looks more like the one for "exclusive famous paintings" which are rare to come by, and difficult to transact, in other words, a kind of highly speculative and not  very liquid asset with high price that is rarely moved, and only to move big amounts of value (not a currency at all, but a "settlement layer for rich guys doing things where fiat cannot go").  

Bitcoin is a settlement layer by design.  No hard fork can change that.

You can use other layers on top of bitcoin for fast and cheap transactions.  One example which dates back to the Satoshi era is payment channels.  Unfortuately they never worked due to malleability.  Segwit fixes this bug, and makes it possible to use payment channels safely.  In the mean time smart people have found out how to connect payment channels in a network, called the lightning network, how to extend the chain with sidechains, etc.  All of them depend on this bug to be fixed.

The block size becomes a very important economic parameter in the future when the reward from txfees is much larger than the block reward.  With large blocks this will happen faster, and we still don't have a solution to the problems which will arise then.

But in all of this, you don't even need to run a node.  You can just connect your light wallet to one of the miner pool nodes.

Yeah, or just use PayPal if you want to trust a thrid party.  Actually I think PayPal is more trustworthy than the miners.  That's why I chose to run my own nodes.

The point is, you can ask for the books of PayPal, or you can ask for the books of the miners.   That's what you do when you use a full node.  But you cannot change them, and there's only one book out there.  If you think that PayPal has been cheating in the books, you could go to a judge.  If you see that the miners have been cheating, I don't think you can go to a judge.  You can just curse them, and that's it.   If the one book that is out there is not to your likings, what are you going to do about it, apart from shouting, cursing, trying to tell everyone not to use bitcoin because it is a scam ....

Yep, and this is why I would never use Ethereum or any coin where the miners can change the rules.  I would be out before you could blink.  Exchange it for PayPal or something.

This won't be a problem, since old nodes don't generate segwit addresses.  You can pay him with your segwit coins, and it is secure.

Ah, I didn't know you could go back from a segwit address back to a legacy address.  How can the old node check that transaction, given that he doesn't have the witness data ?

For segwit transactions security would revert to just a little better than SPV.  It is the same as with e.g. P2SH transactions, OP_HODL, etc.  Of course privacy will still be better when you run a full node.

Suppose that I had coins on a legacy address A1.  I transfer them to my new segwit address S1.  Now, Joe, running an old node, has address A2.  Can I transact coins from S1 to A2 ?
But, suppose now that I had coins in S1, and I pay Jack, running a new node, in S2.
I could try to spend S1 to A2, because Joe, with his old node cannot see my transaction from S1 to S2.

Wrong.  Old nodes still see the transactions, and their UTXO set will be updated for all transactions.  Only the witness is segregated.  This is necessary, because transactions spending coins not in the UTXO set are invalid, and blocks containing them would be invalid.

But of course, the *miners* will not accept my transaction from S1 to A2, because that would be a double spend.  In other words, Joe, with his old node, cannot see that I'm doing a double spend, and would cheerfully accept a chain with a spending from S1 to A1 (if this is even possible ?), but he TRUSTS THE MINERS that they won't allow that.

This is just completely misunderstood.  No node, old or new, will accept S1 to A2 when S1 has been spent.  If the old node didn't see the S1 to S2 transaction, and S2 was spent, it would be a hard fork.

What's the point for him to run his old full node, and not a light wallet connected to a miner node ?

Better security and privacy.  The old node will only be useless for mining.

You may argue that segwit is a cleaner way of doing things, but there is no need to hard fork for it.  In fact it will be very stupid to hard fork for a simple change like that.  P2SH was a much more intrusive change, and it was done by a simple flag day activation.

The point is that if you do a radical change in the protocol, you fork anyhow.  There' s no good reason to keep backward compatibility with software that doesn't understand the new protocol but simply "allows it".  The coin after is not the same coin as the coin before.  The protocol is different.  The only thing that is the same, is the ownership of coins.

Eh, yes.  As long as you don't break any rules, the coin will be the same.  Why the f*** would anyone want to split into two coins for simple upgrades like P2SH, new opcodes like OP_HODL or segwit?  It doesn'ẗ make sense to me at all.  Only a badly designed coin would do that.

And a clean hard fork would also allow people to "not be tied to backward compatibility".  Many crypto currencies have such a policy.   There's a lot of clumsiness in the requirement of a soft fork that disappears with a hard fork.  For a radical modification like this one, a hard fork is much cleaner.

Use one of the scamcoins, if you want an insecure coin which hardforks all the time.  Don't think you will be able to convince all bitcoin users that would be a good idea, and then you have two coins, disruption and big losses for everyone.

This is what I call religion.  If you talk about "insecure" and "scam coin", that's not rational.

Call it what you want.  You could call it fiat, where uncontrollable inflation, invalidation of money and outright theft flourish.  I use Bitcoin instead, because I can be certain that nothing like this will happen.

Hell, I'm even sure that you can change the inflation rate in bitcoin with a soft fork too.  If you would allow every first transaction from legacy to segwit address to be spent not once, but twice, you'd double in one go, all bitcoin wallets that switch to segwit.  With a segwit soft fork because it is a new protocol that is "invisible" to the old one, so a soft fork.

No, that is not possible.  That would be a hard fork.  Again, you have misunderstood how bitcoin works.

The whole "leading argument" in this whole business is the irrational belief that non-mining full nodes have any decentralization value, and that old nodes with old node software are important.   Both of these notions are entirely wrong, but they are the fundamental argument on which all of this dispute is based.

Don't try to tell me this is wrong.  I run an exchange.  A small one, about 1 million USD in monthly volume now (times two, if you count buy and sell separately).  Quite often when people sell coins to me, it first takes them ages to sync their old Bitcoin QT node.  There are thousands of old nodes out there, and people who run them.

You could also just run a full node for your customers, and tell them to connect a light wallet to your node.

Or I could just use PayPal.  Seriously, do you really consider this an option?  Why do you use bitcoin at all?

[dinofelis]

These modifications don't seem like difficult to do in 4 months, right ?

Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.

Not really.  If you keep your old node running, you copy the the old fork, if sufficient miners go with the old fork to still make some blocks.  If you download the new node, you copy the new fork.  

And lose bitcoin.  How well do you think that will be welcomed by the greater community, and how much would you trust a currency whish did that?

You never lose bitcoins because you run a non-mining node.

This is wrong in so many ways, you obviously have no clue.

Of course not.  Whatever happens on a non-mining node doesn't alter anything on a block chain (apart from sending goofed transactions eventually). 

Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.

Forking happens by miners.  And as long as the original chain is one of the prongs, your coins exist of course on the original chain.  You are perfectly right that the ETH fork (by miners !) was done to reverse certain actions by one participant (the "dao hacker"), but he kept his holdings on the original (ETC) chain.

Note that the forking is done by people building block chains and in a PoW system, these are mining nodes.  Non-mining nodes cannot alter the block chain, and hence cannot alter any protocol, or any block chain contents ; as such, they cannot "lose coins".  If by running a certain non-mining node, you've "lost coins", you can easily get them back: erase your node, and start another one with the "right" protocol (the one that can read the chain that has your coins out there).

[sturle]

The original blocksize was 32mb and the 1mb was temporary anti-spam measure.

Not correct.  No version of bitcoin has been able to handle blocks larger than 1 MB.  When the 1 MB limit was set, bitcoin would still choke on 1 MB blocks.  Miners producing much smaller blocks would win any race, because nodes receiving the 1 MB block would crash.  Large blocks wouldn't propagate to other nodes.

Researchers have figured out that blocks larger than about 4 MB would be unsafe.  This is why segwit is capped at 4 MB.  If it was a way to make bitcoin work just as well with even larger blocks, it would probably have been implemented in segwit.  Fortunately the parameters have been chosen by scientists, not users.

The stubbornness and refusal to raise the limit created a side effect of bad business policy

The limit is a hard blockchain rule, not a business policy.  Splitting bitcoin in two would not only be a bad technical decision, it would be bad for businesses as well.  Especially small businesses like mine.

I do wish people on here studied accountancy like myself, then people would have a better understanding of Bitcoin.

LOL!

Btw, the economic properties of the block size limit become obvious when the txfee rewards are much larger than the block reward, which is going to happen faster with larger blocks.  It will no longer be profitable to build on a new block for a miner.  Instead he will try to steal the fees from the previous block by mining a new block at the same height, at least until the fees from waiting transactions in the mempool are higher than in the last mined block.  Thereby leading to steadily increasing txfees.  This is what miners want, not necessarily what users want.

[dinofelis]

If you receive a transaction on your node, and it is confirmed, you will regard it as a good one.  The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently.  So you will lose coins, and can easily be scammed.

That's not what I'd call "losing coins because you run a node".  The coins are what they are.  You may be ILL-INFORMED about what's the status of a coin, yes.  But as long as you don't take any action, the fact that you run a node or not doesn't make you "lose coins".

BTW, of course, if you have a node that looks at chain A, this is not saying anything of what happens on chain B.  If you run a litecoin node, it doesn't tell you anything of what happens on the bitcoin block chain either.   In fact, it isn't even your *node* that matters.  What matters are the chain(s) that are existing out there, and which can be found on the miner pool nodes that make them.  So if you take a light wallet, and you connect that light wallet to a miner pool node that makes the chain of your choice, whatever it is, you'll be all right, and get the right information.  A "right" full node can only copy it at best.

And as soon as you spend them, you may be victim to an attack where someone copy your transaction to the other chain, and receive your coins on both chains.

That's evident that if the chains have identical signature schemes, and you didn't do anything to split them, of course a valid transaction on chain A will also be a valid transaction on chain B, the famous "replay attack".  The thing to do, is that ideally, the one forking off should modify something in the signature (hard fork !) so that this is automatically solved (a good signature on one scheme will not be a good signature on the other) ; or you should mix in yourself newly mined dust on one of the two prongs.  Otherwise, it is normal that any signature on one chain will be copied over to the other chain.

But all this has nothing to do with "running the right node".  You should construct the right transaction, and that's done with a wallet.  A light wallet can perfectly well make a good transaction.

 Unless double-spending protection is in place before the chain splits.  This was not the case with ethereum, and many lost their coins on one of the chains due to this vulnerability.  None of the bit-altcoins address this problem properly in their attempted chain splits, and this is why exchanges won't adopt them, even as altcoins.

As I said, the best solution to handle this is by using some mined dust on each of the prongs, to make transactions that are only valid on one branch.  But ideally, those forking off from the original chain should ideally make something incompatible in the signature scheme (hence, making a hard fork).  

If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already.  It doesn't, because people want bitcoin to be a secure store of value.

It doesn't, simply because of the mechanism of immutability, which, however, can break down if centralization occurs and there's a collusion of more than 50% of the consensus (= hash) power over a change.

> 50% of hashpower can only restrict activity by refusing to mine certain transactions.  They can not change the consensus.  If they produce invalid blocks, the hashpower is worthless.  Nodes will just throw their blocks away.

More than just restrict activity.  ANY soft fork is automatically imposed by a >50% hash rate collusion over the soft fork.  If tomorrow, >50% of miner nodes decide to impose segwit, then segwit will be.  Other miners have no option.  They will get orphaned all the time according to their own rules.  Because all nodes will accept segwit blocks like "legacy nodes", including the non-segwit miners.

Any soft fork is imposed by >51% hash rate collusion.  

Yes, blacklisting addresses is also a soft fork, and is also imposed by >51% hash rate collusion over that black list.

A hard fork is a whole different affair: you make two coins, and users happen to possess both of them.  Up to them to use both of them, by running their respective wallets (and eventually, their respective nodes).

[sturle]

You never lose bitcoins because you run a non-mining node.

This is wrong in so many ways, you obviously have no clue.

Of course not.  Whatever happens on a non-mining node doesn't alter anything on a block chain (apart from sending goofed transactions eventually). 

Dude, I explained several ways.  Don't tell me not just because you don't understand them.

Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.

Forking happens by miners.  And as long as the original chain is one of the prongs, your coins exist of course on the original chain.  You are perfectly right that the ETH fork (by miners !) was done to reverse certain actions by one participant (the "dao hacker"), but he kept his holdings on the original (ETC) chain.

No, miners can't make a hard fork on their own.

Note that the forking is done by people building block chains and in a PoW system, these are mining nodes.  Non-mining nodes cannot alter the block chain, and hence cannot alter any protocol, or any block chain contents ; as such, they cannot "lose coins".  If by running a certain non-mining node, you've "lost coins", you can easily get them back: erase your node, and start another one with the "right" protocol (the one that can read the chain that has your coins out there).

Sorry, you don't make any sense.  Please go back and read how you can lose your coins in a chain split.  There will not be one blockchain, there will be two.  If you e.g. spent your coins in one of the chains, and the receiver copy your transaction in the other chain, you have lost coins in the other chain.  If you receive coins in one chain, the coins may not be valid in the other chain.  In both cases you have lost coins.  Erasing your  node and reinstalling it won't get your coins back.

[dinofelis]

You never lose bitcoins because you run a non-mining node.

This is wrong in so many ways, you obviously have no clue.

Of course not.  Whatever happens on a non-mining node doesn't alter anything on a block chain (apart from sending goofed transactions eventually).

Dude, I explained several ways.  Don't tell me not just because you don't understand them.

Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.

Forking happens by miners.  And as long as the original chain is one of the prongs, your coins exist of course on the original chain.  You are perfectly right that the ETH fork (by miners !) was done to reverse certain actions by one participant (the "dao hacker"), but he kept his holdings on the original (ETC) chain.

No, miners can't make a hard fork on their own.

Note that the forking is done by people building block chains and in a PoW system, these are mining nodes.  Non-mining nodes cannot alter the block chain, and hence cannot alter any protocol, or any block chain contents ; as such, they cannot "lose coins".  If by running a certain non-mining node, you've "lost coins", you can easily get them back: erase your node, and start another one with the "right" protocol (the one that can read the chain that has your coins out there).

Sorry, you don't make any sense.  Please go back and read how you can lose your coins in a chain split.  There will not be one blockchain, there will be two.  If you e.g. spent your coins in one of the chains, and the receiver copy your transaction in the other chain, you have lost coins in the other chain.  If you receive coins in one chain, the coins may not be valid in the other chain.  In both cases you have lost coins.  Erasing your  node and reinstalling it won't get your coins back.

You should try to understand what a hard fork is.  Miners are making two different chains from a certain common block onward.  In a bilateral hard fork (the simplest to understand), the rules that say that a block is valid on one of the prongs, say that a block is invalid on the other prong and vice versa.

Whether other nodes copy these data blocks or not doesn't matter in fact.  Miner pool nodes are building one prong, or the other one.  Without them building these chains, nobody can get them, and the ONLY chains they can get, are these two chains because nobody is making any other one (by definition of "non-mining").

As a single chain defines a coin (by the creation and transaction rules on that chain), after the split, we have two different coins, which are just as different as bitcoin and litecoin.  Satoshi has been mining bitcoin all by himself for quite a while in the beginning, so a miner can very well make a block chain without any non-mining node being around.  No other node was around at that time, and nevertheless the bitcoin chain was made at that point.  Satoshi could have made some fun, and could have made a hard fork at a certain point, making two prongs, and continue mining on the two prongs.  If those two prongs would have continued up to today, we would have had two different bitcoins.  Whether non-mining nodes were looking at that time or not.  So, Satoshi, all by himself, could have made a hard fork, and two coins emerging from one.

There wouldn't be any other chain around apart from these two chains, with a common origin.  These chains are, by definition, made by miner nodes (chain builders).  And nobody else is needed ; and nobody else can make anything else without, himself, becoming a miner.

Of course, you can "lose coins" if in one of the chains, there's a rule that denies the existence of your coins.  But that was the protocol that miners used to make that fork.  Not your node's fault.  If tomorrow, bitcoin is split in two, and in one of the two forks, my addresses are considered spent, then I lost my coins.  But that is because the miners that decided to build that forked chain, decided so.  Not because I was running a node or not. 

[Paashaas]

Hmm, i didn't saw any discussion about BU not a singel time...

BU is even more dead than i thought 

[-ck]

Hmm, i didn't saw any discussion about BU not a singel time...

BU is even more dead than i thought 

Even Roger Ver is part of the coup attempt by miners WITH segwit. BU was a distraction and should be forgotten. It's totally irrelevant to this next round of clashes.

[hv_]

Hmm, i didn't saw any discussion about BU not a singel time...

BU is even more dead than i thought 

Even Roger Ver is part of the coup attempt by miners WITH segwit. BU was a distraction and should be forgotten. It's totally irrelevant to this next round of clashes.

I still like multiple also opposing efforts that are about to improve bitcoin and do not care about impl quality at first sight - otherwise you stay on old stuff for ever.

The hardest task is to filter and merge - and here we need to have room for good old evolution - winner takes all.

[BillyBobZorton]

1) A few companies, i.e. people in suits don't define Bitcoin.
2) The people who are stating that there should not be a block size limit at all are uneducated idiots.
3) "Consensus reached" articles are written by even bigger idiots.
4) The agreement has already failed:

That picture puts it clear. Then you have BitFury's George also parroting another confused notion of the agreement. How many version i've heard of this so called agreement already?

This is what happens when you put a bunch technological illiterates together in a room while disregarding the top bitcoin developers which actually know how stuff works.

This is just ridiculous. If they don't want UASF, then let's get a compromise to get segwit activated right now, with miner agreement, with a soft fork as originally intended, then an eventual 2MB blocksize with a planned hardfork with a good 1+ year. This is what a lot of people are seeing now as the next reasonable step.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html

This looks like a good idea. Reduce it to 80%, so we need that supposed same 80%+ that Barry got, to do some small changes in the agreement. If they rejected this, then UASF will be the only way out, but please let's try first to reach that agreement. I don't want to see 2 coins in exchanges, it will kill the current uptrend.