Topic: 2X - page 2. (Read 4187 times)

To be honest, it is pools that are controlled by the minority, I am not so sure about the mining itself. Miners can always switch pools if they disagree with the voting of their pool. These pools still hold more power then they should, that is for certain, but it might not be that catastrophic. Ultimately the responsibility for decentralization goes to the miners and not necessarily the pools.

Can you give me the source where I said this, even indirectly? (Hint: Never - not even the first part. )

Timing was always my biggest concern when talking about the concrete Segwit2x proposal. IF there was a need for a 2MB fork, I would have proposed it for mid-to-late-2018 or 2019, with one year for preparations. This would be still in an "early" stage of Bitcoin evolution, like I wrote two posts ago.
(My favourite to achieve the "2x" part would have been a soft fork with a bigger discount for witness data, like proposed by the user mezzomix. However I don't know the technical feasibility of that proposal, possible disadvantages, etc.)

Sometimes it is good to change development team, especially if it has people like Luke Jr

I supported segwit activation, including BIP91, what's your problem?  

(and BIP91 was about maintaining compatibility between S2x and Segwit, nothing to do with the NYA as you seem to believe)



So, explain to us again why a blocksize to support billions of users is needed next month, and why we need to hard fork to a different development team to deliver it

I would not be so conservative You can assume that your desired "final" userbase is the entire world population, and that they would do most of their transactions via LN and sidechains. And even then you would need a certain minimum block size if you take into account that for security LN needs a generous space for settlement transactions, to avoid nodes being able to "rollback" channels. I haven't done that research (at least not using scientific standards), and nobody did as far as I know, so I don't want to dig deeper into that. But with a quick calculation I did some months ago, I came to the conclusion that if we want a user base into the billions, the 2-3 MB offered by the current "Segwit1x" configuration would not be enough.

About your never-ending personal attacks: We have Segwit now. I don't think I personally contributed to it with my "Segwit2x shilling" (as you would call it), but the Segwit2x initiative definitively did. The UASF move you supported may have worked, too, but would have been much more risky. Politically, the "direction" I supported was successful for the good of Bitcoin, so what's your problem?

So, Bitcoin reached it's "final" ideal userbase numbers, when was it, yesterday?


Forget it d5000, you're still talking technical issues (which are not in S2x's favour) when the fork is still a political move dressed in technical clothing. It always was, and this is the 4th such attempt to make this false assertion about blocksize. And how many times exactly have you personally been involved in blocksize conversations while ignoring the political elephant in the room? It's very tedious, and does your credibility in these matters no good.

There's just no credible empirical evidence that the blocksize needs increasing now, even to the current 4MB maximum, and you do nothing but drone on about future ideal maximums being desirable next month. You do nothing but talk constantly about positive aspects of blocksize increases from as many different perspectives as you are able to summon up. C'mon.

Well, there is a possible advantage I can see: The blockchain capacity achieved with Segwit2x could be the ideal "final" size necessary for Bitcoin to become "massively used as a currency". Obviously the whole concept would include second and third layers like Lightning Network and sidechains, but a blockchain with 2-4MB Segwit blocks alone may be a little bit too small to serve as a settlement layer for all these second-layer solutions.

If that assumption is true (it may be not!), then it would be not a bad idea to do the hardfork in the current stage of Bitcoin's evolution, when the network is still young, there is not too much at stake (at least, no critical services like healthcare etc. are depending on it) and so it would not be the end of the world if something goes wrong. In a later stage, such an hard fork may be more difficult and painful.

However, if this argumentation is used, there would have been research been done if 2MB+Segwit (realistically 4-7 MB blocks, 8MB max.) are really the ideal size for a "final stage Bitcoin main chain". This research has not happened, as far as I know.

this is correct, and I think the way to look at it is this: who can benefit from the Bitcoin system?
The community - aka the vast majority (e.g. running core nodes) definetly did not express their wish to use SegWit2x.

The miners would like to have SegWit2x. By this they are willing to take the vast majority of users as "hostage", to follow "their" will. This prevented already in the last 2 years the bring-in of SegWit, and with it the further development of the Bitcoin. Wether this was intentionally or accidentially, I don't want to judge.

The work of the miners is to stabilize the network, and get the incentive for it. As mining is more and more centralized, this is a super-vast minority, which from my point of view should not be in a position, to decide, what the super-super vast majority wants. I see, that many companies also signed the NYA. So what? This still doesn't make a majority.
There are more developpers listed on the bitcoin.org webpage (aka "core developpers"), then people/groups/companies in NYA.

I understand the community does not accept a minority giving direction against the way, the core developpers take.
And also I can see, that majority of SegWit2x people tend to think, that core devs are two or three names (Luke Jr, Greg Maxwell and Adam Beck). This is not the case, as I just showed with a look at bitcoin.org (there are hundreds of names). Looks like the SegWit2x group does not (want to) understand, that the concept of Bitcoin is a non-centralized system, where a single group or person is prevented from changing direction. There is no "king" or "government" in Bitcoin. With the current situation miners and NYA teams play the role of a government, and this contradicts the main principles of Bitcoin. 

While most users talking here seem to be against SegWit2x, especially because for now it doesn't bring anything new and helpful, the miners are all for it.
If you look at coin.dance or xbt.eu websites, SegWit2x (or NYA) has well over 90% support.

Who wants 2x? Seems like the compromise that no one wants.

I don't know what it was created for and I would say it doesn't really matter. All I am saying is that it is completely possible to use it for that and there are costs if you don't use it. But we will see. no one can know an average number when the thing doesn't even exist yet.


There us a reason I called them well known nodes and not trusted nodes, because trust isn't necessary in a Lightning Network, that is the whole point of it. If trust was needed, we would just use banks instead.

Ok thanks I will have to go and research this some more.




I address this more appropriately infra. (my error for using 2X by the way).



If my simple math's holds.
If block size 1 = x, and
fee = y, and
number for transaction to fill block = T

then fee = yT

if your block = 8x and your fee = y/2 then it would cost you

8yT/2 = 4yT, and 4yT/yT = 4. So in this case at half the fees, it would cost 4x the cost to fill the block and so on.

It seems this model really costs the "spammers" more to get their market signal in,  

BUT I was wrong not to consider demand as you rightly pointed out.

I must accept your zero fee argument insofar as demand does not drop of linearly with block size increase, probably more like a some sort of auction curve for the last unit (s)of space, so perhaps quasi Multiunit auction? Intuitively the curve seems to be perhaps sigmoidal in shape ~ S= 1/(1+e-t)?

Does this exclude some break point where the you can get better market signal at a lower final price point in the blocks, and this may mean a 1.1MB or some small percentage and you use some sort of function as you also seem to suggest (more on that infra).



Yes, I accept you point in relation to the demand side of things, but can we more closely match demand as stated above?


My error, I should say 2MB or as the case may be 1.1MB or whatever.

More on point, Do you consider there would be an appropriate increase in the face of increasing demand, or more specifically

Is there perhaps a  function or family of functions that could say give a optimal or near optimal blocksize given a demand and fee cost curves? You seem suggest a few percent, which in light of the above seems right.

It seems reasonable to say that demand has risen and there may be and appropriate blocksize increase at some point. Of course the functions may show that the blocksize is too large already, as I do not know the functions. However it seems some size increase should be mooted in the face of a level of demand.

This may allow 2 advantages

[1] Some certainty on scaleing
[2] Trying to get the best market signal

Thanks in advance.

Yeah, this is real problem. Here i agree with you.

Lightning network was created mostly for small payments. For example you open channel with some product shop. Or with your friend. Of course, you're able to use others channels but in that case you must pay fee as you know (and also it is risky idea. hackers don't sleep). So someone will close 10 channels per year, another - noone. So i took average number. 

Lol, this is some kind of exisiting bank system. Trusted nodes == banks.

Well, gmaxwell noted that Bitcoin Cash have now implemented Segwit and Segwit native addresses (i.e. the BIP173 Bech32 format), hilariously calling them alternative names, despite heavily promoting a supposedly superior tech to solve quadractic sighash DoS attacks and signature malleation.

So what's the actual difference between S2x and Bitcoin Cash in technical specification? While not identical, increasingly less (possibly Bitcoin Cash has the technical edge right now with their BIP173 deployment). And in market terms, Bitcoin Cash has a network, software running that network, a price, and a track record. S2x apparently has a promise of hashrate. I wonder how S2x futures prices are doing?

Why? It's not as if anyone involved with BTC1 is a prolific Bitcoin developer. I have doubts that they are capable of even merging Core's updates. I think they expect(ed) that the NYA and existence of BTC1 would be enough to force Core to merge the 8x consensus change. I'm glad to see they were wrong.


I think this will be the explanation provided. There will be no more major changes, just final testing of the consensus changes. And politicking. I actually won't lie: the No2x crowd and their obnoxious hats sort of piss me off, and the whole BIP148 thing really pissed me off -- particularly Luke's role. But I've always been against hard forks and contentious forks in general.

I am a bit surprised to see such low activity in the BTC1 repository.

We could now draw the conclusion "Segwit2x is dead", like WhalePanda already did in a blog post,  and party because the (tremendously dangerous - at least compared to the kindergarten BCH fork) November fork won't happen. To da moon!

But perhaps is there another reason for that low activity - maybe the client is "ready" and won't see major updates until the fork, to not over-complicate things? If someone has insights there, I'm interested.

(I have advocated for Segwit+2MB proposals in the past, but now I'm pretty neutral regarding Segwit2x, sympathizing perhaps now a bit more with the "no fork" scenario, because big blockers already have their play money now, we have Segwit, and the hard fork date is - in my opinion - way too early. In short, I wouldn't cry if Segwit2x was dead.)

Are you that sure about that number that you will have all the dangers of a hard fork with no replay protection when it is years, maybe even decades from potential necessity?

I can very well imagine that everyone might use one big Lightning Network in the future and that there will be no need of ever closing it. There is also a cost to closing a channel, so there is an incentive of not paying mining fees that people might not want to ever close it. And people might not worry about the benefits of closing a channel as much as you think, since the only benefit is that there is no risk of your funds being lost. It makes sense to assume that people will not open a channel with a friend, but with a big well known node that has open channels with many other users. That way if that well known node betrays the well established trust starts closing channels, everyone would know about it, since it would be a big deal and maybe even be in the news and that could cost that node a great deal. This node won't be able to close all the channels at one either, since it will be literally impossible to put so many transactions in blocks. Here a bigger block size is actually a problem. You see, it isn't all that simple.

But I can tell you this, the benefits of S2X are none for many years to come and costs and dangers are huge and there is no cost in postponing the fork and there are certainly benefits to do so. This is obvious to anyone who thought about it for a reasonable amount of time, which tells you something about that NYC agreement, whatever you think that something is.

Yeah, but 104 million transactions it's enough only for 52 million of users. Also, i didn't counted another types of transactions like transaction with big amount of btc (Lighnting network is desined for small payment), multioutputs and others. So real number of users is much less than 52 millions



Thanks, it was interesting to read. Yeah, i agreed with author - hard forks it is very dangerous way.

Other people already had. I was clarifying the innovation point and nothing else.


What "decrease"?.... on state of the art hardware at both times the initial sync of Bitcoin increased by 50% in the last 6 months.  This has a material impact on people's willingness to run nodes-- an uncompensated act which is essential for Bitcoin's survival as a secure decentralized system.

Twice the space doesn't mean one half fees, it means almost zero fees against the same demand. Half the fees would generally be achieved by a few percent more capacity.


A spammer must pay the fee of each transaction they displace for every block they displace it. Increases in blocksize in excess of demand just radically reduce their costs by resulting in very low fees.  A lager block never lowers the price to displace a transaction for a spammer.

The best prior research we had showed that 2 to 4MB was the largest arguably safe amount even while ignoring safty margins, state attacks, initial synchronization, etc.   2X is _NOT_ 2MB, it is 4 to 8MB.

I heard that remark a while ago. Luke may not be on the same level as many of the other Core devs. At the very least, that remark was made when people should have been finding cheaper transactions due to scaling limitations. That being said, scaling solutions are being undertaken, and if lightning network with Segwit isn't enough, then 2X can be considered. Several of the Core devs have made it very clear that there is much more to 2X than just a change in the block size. A change in the block size has much larger dynamic implications which can not be predicted. Once 7 billion people are using BTC, trying to transact and close lightning network channels, 2X or 3X or nX can be considered, but why take chances on something that were not ready for? Eric Lombrozo has made comments on 2X that you might want to consider here:

https://bitcoinmagazine.com/articles/bitcoin-core-developer-eric-lombrozo-on-misunderstandings-in-block-size-debate-1455817458/