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

Can we keep the tinfoil-hat stuff out of this? 

Looks like Tone Vays and Trace Mayer joined the UASF team. I see UASF to continue gaining traction as miners keep fucking around. ASICBOOST needs to die, if Jihan keeps avoiding segwit softfork to keep milking fees he's going down in history as the goliath that destroyed by an army of UASF davids.

Given that I run one on what is considered "small" bandwidth (10M down 0.5M up) by modern standards, I'm not sure I'm seeing that as a viable reason/excuse.

Edit: I'm not sure I see the logic in throttling a protocol because some potential users cannot utilize the same bandwidth as "Hillbilly Wireless" (and, yes, that's actually my ISP)

*sigh*

There is no point in variable blocksize, because there's no way of stopping it being turned into "gigablocks by midnight", your caricature of preference when it comes to making a point, seeing as you've got no valid arguments against the fact that variable blocksize is easily gamed, hence your moratoirum on that argument in your so-called discussion thread.

And my argument, that you didn't anticipate having to censor, was that allowing such tiny increases is pointless anyway. It's not the size of the increase that makes the slightest bit of difference, it's the actual method you're arguing for, "market driven" variability in blocksize.

See if this can penetrate the thickness of your skull: the market includes people that don't like Bitcoin, and want it to become centralised and fail. Those people will push the blocksize as high as possible no matter what cost to them, and the more well financed such opponenets are, the more likely they are to throw every resource they have at raising that blocksize to the absolute max.

Hence, blocksize should always be a programmed constant, with step changes, sure, but a programmed constant, just like the coin supply. Now, argue that (irrefutable) point, or shut your mouth

It's been 4 days since I restarted my Bitcoin node (in order to make a configuration change) and I've uploaded 300 gigabytes of data to peers since then. I'm on track to upload over 2 terabytes this month.

A block size increase will increase the bandwidth required to run a full node.

Increasing the bandwidth required to run a full node will certainly reduce the amount of full nodes. It's up to the user to decide if that is desirable or not.

As a member of the community who is totally uninvolved in either mining or development but who nevertheless has a substantial interest in bitcoin I kindly request the all parties commence immediately with the necessary chest thumping so we can move on to the halfway point bolded above.

Someone, please remind me why we need any size limit in 2017; when CPUs are pushing 100 GFLOPS and GPUs are pushing 10k, surely more can be processed than produced...
Why are we still sitting with a 2011 mentality? 

That sounds good in principle but alas the miner agreement does a lot wrong that core can't condone. If they were to run with core's segwit implementation and a 2MB hard fork it would be different (as already proposed on the mailing list), but the agreement goes to great pains to say that segwit will be on a different bit implementation and be activated concurrently with a hardfork. Core can't agree to something that undoes the existing implementation which won't expire till November to adopt their more radical approach. If core agrees to do segwit followed by 2MB HF, it has to be with their existing implementation or they lose the next 6 months' opportunity to activate the heavily tested prepared segwit component already. The mining consortium has to ease their stance to meet them or we do nothing for another 6 months again or fork galore or risk an outside provided code base to work off. BU proved that's not a safe option with their incredibly unstable implementation of just one feature. The miner agreement is one by people who appear to not even know what they're agreeing to and ignores - or doesn't understand - what is realistically doable in a safe manner. The halfway point is core agreeing to their current segwit implementation AND a 2MB base blocksize hard fork that they implement - it's my gut feeling that's what we'll end up with but there needs to be a lot of rhetoric, chest thumping and circle jerking in the interim.

That's a fair bit of verbal fluff just to voice the view that you don't personally think it's a valid design.  Did you have anything else to offer besides opinion?  Also, you can't argue it's "negligible" or "pointless" when you yourself clarified in the other thread the small potential of a maximum 8.16MB combined base and witness after 4 years.  Or is that what you deem negligible now?  Plus, if I had gone with larger adjustments, potentially resulting in larger increases, you no doubt would have bitched about the possible threat to node decentralisation and the usual 'gigablocks by midnight' nonsense.  There's literally no pleasing you.  If it wasn't proposed by Core, you shoot it down by fair means or foul.

The lack of code is probably a good thing at this juncture. I have been following this dispute only recently but the strong impression I get is that the only possible path to consensus on something like the miner agreement is if the code is ultimately produced, vetted and shipped by the core developers.

The miner agreement at this stage is simply a proposal. That proposal must now be vetted by the rest of the community to determine if a grudging consensus can be built around it.

Hopefully such a consensus will be possible. It strikes me as a far healthier path forward then stagnation forever in the current state or a civil war leading to a split into two coins.

You're wrong.

You may as well pull out Keynsian economics arguments in favour of making the 21 million BTC supply variable too. It's been explained to you a million and 1 times why variable blocksizes are not a sensible design, but you put your fingers in your ears and start shouting about variable blocksizes again, in a vain attempt to wish all the problems with that idea away.

Variable blocksizes do not have any valid design, you tried to make the design valid by making the variability neglible, and therefore pointless. If, and let me repeat, if, someone can design a variable blocksize algorithm that's actually going to work in this inconveniently real world, by all means, make the case. But in the meantime, seeing as no valid design exists, please be quiet

That's about what I thought, just wanted to be sure I was getting it.  

It actually takes time and effort to make pools signal something different. Pools, being the conservative entities that they are, will only change when they have a clear thing to change to. Their miner agreement clusterfuck has yet to produce any code for them to use to signal with so they'll just leave everything as is for now.

2009 the year when Bitcoin went live.

21 millions bitcoin in total.

hopefully the 9/21 will not become the 9/11 of Bitcoin.

EDIT: ok, the HF will be moved to December.

OK, someone set me straight...
"BU is dead", "BU is nothing", "BU is irrelevant"...

BU is still well above 1/3 of the hashrate signal (AntPool-16.77 %,BTC.TOP-10.06 %,ViaBTC-4.19 %, etc).
Bitmain, who supposedly signed this agreement, is still signaling the same as they have been.

 

Yes, this is so evidently true that it is scary to see the denial over it.

I think you're right, that if one had to re-design bitcoin into something with a 2-tier network, with an on chain settlement layer and an off-chain payment layer, that the settlement layer should never have a hard limit, because it is an element of trust and security.  In as much as "not getting your transaction through" is annoying with transactions as a scarce inelastic resource, it is not a security issue.  If you can't pay, you can't lose your ownership either.  If, however, *publishing potential tranactions* are the security element, they have to have a guarantee to be able to get published.  Any form of scarcity of transactions becomes then a security issue.  That doesn't mean that it has to be free, but the LN needs a guarantee that any settlement transaction is going to be included within N blocks where N is significantly lower than the "time-out" of the security.  If the LN has the ambition to become much bigger than the current bitcoin network, then the on chain capacity should *have the potential* to settle it entirely in N blocks, and even have a mechanism to guarantee that settlement.  

Otherwise, you have the equivalent of in total only 5 appointed judges that have to deal with all potential contract litigations, and only consider litigations when the problem is less than a week old.  If the number of contracts within these 5 judges' jurisdiction is one million, then as a contract subscriber, you are at the mercy of a judge having time next week to settle your problem if you're scammed.  If enough people get scammed, most scams will get through, because the judges can only settle so many cases per week, and all the others will never be treated.

Add to that the funny part that these judges are also responsible for judging parking tickets, the day that everybody gets scammed, there are also 5 million parking tickets to be settled.  (spam)

No, the LN without a mechanism of guarantee of settlement on chain within N blocks is outright dangerous.

That said, my question is: why on earth would one want to re-design bitcoin and not simply do this elsewhere on a different crypto currency, made for the purpose ?  After all, bitcoin was a system designed to have a single layer of settlement.  Why trying to modify the design of a car so that it can fly and why not design an air plane from scratch ?  People wanting to continue to use a car can do so with the system they used to ; people wanting to go to the new air plane, can switch and use air planes, no ?  I don't see why cars should be transformed in air planes.

Sure.

50% of the validating wallet operators turn lemming and start rejecting everything that is not compliant with the User Activated Segwit Failure.
20% of the miners follow them.
Of the other 80% of the miners, 75% of them activate big blocks of some form or another.
That splits the other 25% in half - half go to UASF, the other half to big blocks.
The big block chain starts processing transactions at 2x (maybe 4x, maybe... what ever the demand is) the old rate.
The USAF chain continues processing transactions, but at half the old rate.
People cant get business done on the UASF chain.
People start abandoning the unusable UASF chain.
Miners follow.
Big blocks subsume 99% of all activity, and becomes unequivocally The Bitcoin.
The indignant hardcore 1% UASF'ers piddle onward in irrelevancy.

Same old mistake everyone keeps making. Variance. Exactly the same pools are signalling/flagging/fapping, whatever you want to call it, that have been for months now.

ooorrr maybe not. Just now: