Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 79. (Read 120014 times)

I very wish the devs would be payed in bitcoin only, than some actual tx issues were already fixed...

I kind of thought bitcoin was supposed to be mined and sustained by it's users who made up a consensus collectively. This seems wrong for a handful of people to be able to decide the future of bitcoin through a few emails or in a secret meeting. I think the biggest mining pools can and probably are accelerating blockchain congestion to extort higher fees and justify changing bitcoin in a way that gives them even more control over it. There should probably be some kind of public investigation into the mining pool situation. I bet they wouldn't even let an investigator into their buildings. owell

Note to self: Stop trying to have logical conversations with fanboys. 

Most people need a day job to pay their bills, yes.

Those are paid by a single employer to do a very specific job, commanded by one commander in chief.  Try again.

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?

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.


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.

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.  The old node will accept the transactions and see the confirmations come as normal.  (Unconfirmed transactions are insecure, of course.  Unconfirmed transactions have never been secure, no matter how the transaction is created.)

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.

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.

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 should join the mailinglist and spend some time on IRC where decelopment is discussed.  Perhaps it will open your eyes.  This kind of conspiracy thinking is just silly.  First and foremost it is wrong, because "Core" isn't developing LN.  There are several implementations of LN, but none by "Core".  Segwit enable a lot of other technologies as well, and some are just as compelling as LN.  E.g. sidechains.

You are the first one I've ever seen to make this excuse.  Sure it isn't a straw man?

I don't think you understand how a blockchain works.  You can't go from 1 to 2 MB of block data, because that would make bitcoin split into two blockchains.  While 4 MB is a stretch as well, there has been a lot of research done on that subject.  It suggests that 4 MB is mostly safe, while larger blocks will not be.  The problems are somewhat relieved by the facts that it will be much faster to validate a segwit block, and there are incentives in place to stop the UTXO set growth.

All "Bitcoin Core" developers are paid and "some [contributors]are not paid by anyone". As I said, this is a significant distinction.
By that logic, the U.S. Marine Corps don't exist, because all Marines are paid by the U.S. Dept. of the Navy.

It's so cute that you actually believe that.
I remember it very well, yes.  Coindesk had an article about it recently.

I never ever experienced a closed door at Bitcoin development.  The developers there welcome any well founded opionions both on the mailinglist, on IRC and on github.  Everything they do is public.  There are no deals done behind closed doors.

By this definition, Bitcoin Core is not a company.

The developers are paid by a lot of different universities and companies, and some are not paid by anyone (e.g. students).  Noone get paid by a company called "Bitcoin Core".  Many are not paid for the work they do on Bitcoin Core, but the work may be done either on their spare time or as a project where they work.

The wider community don't mine.  Almost all mining is done in China.  Miners are just service providers.  Important service providers, of course, but they depend on the rest of the economy to make any money.  If exchanges and merchants don't accept their blocks, they are gone.  What you see now is essentially a few Chinese service providers on strike.  The rest of the economy, more than 90% of it, want the current proposal.

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.  

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.  If you connect to an old-chain miner pool node, then you transact on the old chain ; if you connect to a new-chain miner pool node, you transact on the new chain.  You should be careful to avoid replay attacks, this could be done by slightly modifying something in the signature scheme in the new chain.

There's nothing special about having to download another piece of software if you want to run another coin.  In fact, exactly the same would happen with a UASF or any other such thing.  Monero or ethereum or dash or... nodes also have to upgrade when there's a hard fork.  That's part of the game.


Of course it matters.  That would be nodes that cannot understand segwit transactions.  Yes, they wouldn't refuse the block chain, but they cannot understand it.  It would see funny transactions, but accepted as "anyone can spend".  If I'd pay a user with a segwit transaction, and his light wallet connects to such an old node, he would not see my transaction arrive.  The user of the old node himself wouldn't understand my transaction if I were to have segwit coins and wanted to pay him.  So this would be a crippled node in any case.

As you know in the mean time, I don't believe in the decentralization value of non mining full nodes, but the decentralization value of crippled full nodes that don't have the witness data and don't understand the segwit transactions is even much more of a ridiculous idea.

The thing is that segwit is a radical modification of how bitcoin functions.  I'm not saying it is bad (I think it contains some very good ideas).  But it is a radically different way of doing many things.  Essentially, the legacy bitcoin and the segwit bitcoin are two entirely different things.  A clean hard fork is much more adequate for this.  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.

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.

My own thinking is that Core wants to push people out of the block chain, and onto the LN, because that's their toy, and they think that LN has not much to offer (probably erroneously !) apart if people are FORCED off the chain.  I think that *this* is the whole origin of this crazy list of arguments, that culminates in the absolute importance to the security of bitcoin of an old piece of software running on an old PC somewhere on a 56Kbit link in some basement somewhere in Africa or so, as excuse for not having to increase the legacy-transaction room on the chain.

In as much as "increasing block size to 2 MB" was considered a disaster for our old PC on his 56Kbit link in that basement, visibly increasing witness data to 4 MB was not going to be a problem, because somehow, these witness data were not essential to the security of bitcoin, (you could accept that *someone* *somewhere* had checked them, right ?).  One needed an army of full nodes that were constantly checking the single available chain out there in all of its details (was the argument), but suddenly, that wasn't needed any more for the witness data.
Going from 1 MB to 2 MB was going to kill all full nodes, but going from 1 MB to 4 MB of witness data wasn't a problem.

In other words, one cannot be so naive, as a bitcoin developer, not to know that if there's only one chain out there, only a few full nodes would be sufficient to be whistle-blowers to tell the world the miners are making a false chain ; at which point all users could consider leaving all their bitcoin holdings for what they are and never touch a bitcoin again ; or accept whatever miners find a consensus on, and hope they will still accept your transaction.  And that whether that single chain out there is checked 5 times, or is checked 7000 times in a row, doesn't matter.  The guy finding out that it doesn't check, has news to sell (but most probably will first sell his own coins....).

This whole story of the necessity of a lot of non-mining full nodes, crippled or not, from the moment they do not allow more than 1 MB of legacy transactions, but without any problem, are blind to 3 MB extra segwit data, smells as a fundamental desire of core to asphyxiate legacy transactions, and ONLY legacy transactions.
The poor African in his basement with his 20 BTC transactions (smaller ones are not going to be profitable given that he needs legacy transactions on his old node, and the fees will be high) that cannot afford a 3 TB disk and a better internet link, but has to pay $10.- for a transaction, running old core node software, brings tears in my eyes

This whole story only makes sense if somehow, one wanted to force people off legacy transactions, and all false arguments are good to sell that.  But there's no technical or game-theoretical justification for that.  This is why the story of "no hard forks" and "importance of full-node-in-your-basement" has been propagated in my eyes, because it is obviously false as a logical argument.

It's so cute that you actually believe that.

A company need not be profitable, designed for profit, incorporated, or even successful in order to be a company. Because, English.
Setting that aside, not all "Contributors" are "Developers" and this in an important distinction when it comes to the fact that the "Developers" are paid. So, by all definitions, Bitcoin Core is a "company" and the "Developers" (devs) are in charge of, and paid by/for said company. Because, English.

As for the body of your thinking:
If you were right, a proposal that was slated for 95% and never got 40% would put Core in the direction that this thread wouldn't even exist (as it would be obvious that "the wider community" didn't want it).
Now, I'm sure that someone will try to make that argument that the pools are "in charge" and "the wider community" isn't represented by the wishes of said pools. The only problem with that logic is that "the wider community" has the ability to not mine in such pools.

Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.  And research suggests that blocks larger than 4 MB would be unsafe, so I doubt you will be able to convince 100% of all bitcoin users to "upgrade" to something entirely untested like that, backed only by some secretive backroom dealings.

Segwit as it is with 4 MB blocks can be deployed in two weeks, however.  There are still thousands of nodes not supporting segwit, but it doesn't matter.  Those will continue to work just fine, since it is a soft fork.

You obviously don't follow the dev-list and the developer meetings on IRC.  Everything Bitcoin Core does (it is not a company, btw) is suggested by the wider community, discussed among the wider community, thoroughly tested, peer-reviewed, tested and eventually sometimes deployed under more or less full consensus.  Then, if it is a soft fork, 95% of the miner hashrate have to agree as well.  You will never see this kind of childish closed door deals happen with Bitcoin Core.

If Bitcoin Core would try a coup like this one, most of the developers would leave the project, and it would end up in the trash like "Bitcoin XT/Unlimited/Crashic/whatever".  You may say it already happened, when Gavin stopped beeing a developer, and started behaving as a some kind of ruler who wanted to make decisions on his own without any kind of peer-review or discussion.

I don't know the exact content of the proposition, but I thought it was a single package ?  In other words, a hard fork that includes 2 MB and segwit the way it is right now ? 

Am I wrong in thinking that on the software side, that's quite easy to do with core 0.14.1:

1) change the hard limit on the block size (that's just one hard parameter to change)

2) change the activation threshold for segwit from something like 95% to something like 20% to be sure it gets activated automatically if ever this software is run by more than 20% of miners.

3) change the bit on which the checking is tagged in 2)

4) allow to signal the bit in 3) with an option.

5) by hand, from the moment that 80% of the miners signal this bit, produce a first single 2 MB block, which signals the hard fork.  Now, the two chains exist because old core 14.1 will not accept this block and build on its predecessor, and this modified core will accept it (see 1) ) and make its own chain that is not considered valid by the other nodes/miners.

That's about it, or am I missing something ?

Because this code is itself a hard fork, SW becomes automatically a hard fork even though its implementation as a soft fork can remain.

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

And if ?miners? do not activate SW but rather use the 2MB first ?  Could that happen ?

One could even argue: bigger blocks => bitcoin not a shit coin any more, one can again do some transactions => all speculation on which alt coin is going to take over becomes moot => alt coin over inflated market crashes => this was what had also pulled bitcoin up as a speculative token too, so bitcoin crashes too because no more uncertainty, hence no more speculation, back to economic reality which is much, much, much smaller than the current ~80 billion market cap, back to $2 billion for crypto.

Or, like on LTC: no effect.

One could argue bigger blocks = mempool drained and dumped or sold, lower Tx fees due to larger block space and increased volatility due to lack of Tx backlog.

I agree. It's a good summary.

Remarkably it are the miner pools who want larger blocks.  It is Core that doesn't want larger "base" blocks.

No. Bigger blocks = more txs = more smaller fees = higher value of BTC.