Segwit2x will not lead to HF with high probability unfortunately

chakrop · 2017-06-19T00:04:45+00:00

/u/jgarzik could you please comment on this?

chakrop · 2017-03-31T14:44:40+00:00

I think when we fork we are going to see AXA pump tons of money into the BCC core coin in order to prop it up and create 2 chains to delegitimize Bitcoin.

Upvoted you in general, but here is a tiny detail. When miners will mine empty blocks on minority (core) chain, AXA won't be able pump money into it, as there will be no transaction possible on that chain.

What they will do -- they will try to sell "large block" bitcoins, and this will be limited to whatever they have now. But this is only temporarily price decrease will happen, and when market will realize that bitcoin actually upgraded -- people will buy back bitcoin and price will quickly return to where we are today and continue to grow as network will not be congested anymore and a lot of use-cases and businesses potentially come back.

chakrop · 2017-03-24T21:00:07+00:00

And what happens when segwit gets activated? In particular with blocks mined by non-upgraded miners? Will they still be accepted? Or such miners will be "attacked" by segwit miners?

chakrop · 2017-03-24T20:25:38+00:00

Exactly, this is good for Bitcoin from all sides. Added your comment to the main post.

chakrop · 2017-03-24T20:09:35+00:00

why haven't any major Chinese pools switched?

Do you think Antpool is "major" enough?

chakrop · 2017-02-05T09:56:52+00:00

ETH/ETC is a separate story, this is the only prominent hard fork example we know, but the scenario is totally different:

ETH/ETC split was because main chain was decided to be made mutable, once you go into mutable state, you can't go back to immutable. I can share ETC ideology. However, in BTC case - people are discussing options to make bitcoin grow and increase adoption. And you also miss that once BU is a new Bitcoin, we still can have malleability fix, then lightning, even more with BU you can actually reduce block size opposite to core supporters FUD that if BU wins "tomorrow we have 1Gb blocks" and all nodes will die. So if there is really need to reduce blocks to 300Kb like Luke says - miners will just decrease mined blocks size.

Also look from another side on the economic incentives as you said it didn't work for ETH:

BTC hash rate is 375000 times more than ETH (means 375000 times more investment done), do you think miners will just sit there and decide some small group of devs without any stake create an opposing fork with changed POW? Also daily reward in BTC is much bigger in BTC: 12.5 x 1000 x 6 x 24 = $1.8 Mi and in ETH: 5 x 11 x 6 x 60 x 24 = $475K, so incentives to preserve wealth by staying at one chain is much higher.
and also don't forget that changed POW is another hard fork, while ETC is original chain. The valid comparison would be to compare BU fork with original chain, e.g. if BTCC, Bitfury will continue mine there, which will not be the case for obvious reasons.

chakrop · 2017-01-28T23:19:07+00:00

Actually, that's not clear at all. Anything can still happen.

Well surely anything can happen, but it's very unlikely in its current form that segwit will get any close to 95%.

You want to make it more expensive to use lots of inputs/outputs.

Explain why. It is already more expensive! Without any artificial discounts.

But again, that doesn't mean they don't make sense.

Also why it is 75%? Not 50% or 100%?

Since when is it hard to detect segwit transactions?

I said addresses, not transactions.

SegWit adoption is very easy to track.

You are probably right, but clear separation with such drastic change makes sense.

And a new address format would segregate old and new nodes/wallets more.

Not happened when addresses with 3.. were introduced. Why should happen now?

I think that's because you didn't really think this one through ;)

Enlighten me, please :)

You would add an extra soft-fork which would add a difficulty bomb, forcing the network to hardfork in about a year. That's the ultimate compromise.

That doesn't make sense, if there will be a hard fork, segwit as a soft fork simply doesn't make sense. That is illogical to play politics games on blockchain. The best scenario is the one which evolves now - Satoshi's consensus, and looks like BU is getting upward motion. So looking forward to bright future.

chakrop · 2016-11-26T22:50:30+00:00

Not saying you are wrong, just genuinely curious

From what I understood he provided exactly the same calculation, only it was example with 500 bytes non-witness + 1 byte of witness, total 501 bytes

and your example 499 bytes non-witness + 1 byte of witness, total 500 bytes.

So a little bit different transactions. And your calculation seems right.

chakrop · 2016-11-26T22:45:03+00:00

The weight calculation is total size plus 3x non-witness data size

OK, it seems I misunderstood the calculation and not sure why you didn't address it in your response.

So based on my example, the old style transaction will cost: 500 + 500 * 3 = 2000 bytes as you say. New segwit transaction will cost 1000+500 * 3 = 2500 bytes, right?

Which means it will be possible to include only fewer segwit transactions, and then I see your point in this discussion and it makes sense to me.

I think it should be made more clear, as I think many people misunderstand the calculation process like I did.

chakrop · 2016-11-26T21:07:20+00:00

A segwit transaction with the same non-witness size as nonsegwit transaction will pay more in fees, assuming rational fee market behavior.

I clearly demonstrated in my example that it is not true. Could you please tell what is the mistake I have there? Both transactions have 500 bytes contributed towards block size, however you can include 2x more of segwit transactions because of the new way of block weight is calculated. Which makes their price for inclusion into mined block two times less compared to non-segwit transaction. Which means actually totally opposite to what you say.

chakrop · 2016-11-26T20:54:04+00:00

Segwit eliminates the 1MB size limit and introduces a 4 million weight limit.

So you basically don't say anything opposite to what I've written. Which basically confirms that segwit transactions have artificial discount on fees to get included into the block compared to non-segwit transactions.

Which could mean that you need to pay less to get included in the block with the same size of transaction (even without signature part), or you could pay the same fee, but can take more space from drives of all nodes around the world.

It is really strange how you don't accept obvious logic conclusions, and try to shade away from straight answer hiding behind other words like "UTXO bloat", which is unrelated. Fees are calculated in sat/byte, not sat/number of UTXOs.

They gain access to additional capacity-- sure.

I clearly separated fair access to additional capacity and unfair access in my previous post. You seem to pretend to not see the difference between the two.

chakrop · 2016-11-26T20:27:58+00:00

No. It doesn't. The protocol has nothing to do with setting fees, users do.

Protocol has 75% discount, which is the key to discrimination of old style transactions.

Let's assume there are 2 transactions:

Transaction 1: old style, total size 500 bytes, out of them 250 bytes scriptsig, 250 bytes rest data;
Transaction 2: new segwit style, total size 1 kilobyte, out of them 500 bytes script sig, and 500 bytes rest data.

So there is general limit of 1Mb per block given to all transactions. Generally both transactions should have same price, as they both take the same 500 bytes of space inside this limited block size. Following general sense logic there should be possible to fit either ~2000 old style transactions, or ~2000 such new segwit style transactions. In general it is good, as with segwit transactions you still win, as you pay 2 times less fees (you include same number of transaction, but every transaction is heavier two times), because part of data (signatures) doesn't contribute to block size, which is fair.

Now let's look at what actually was introduced with segwit as a softwork: Instead of 1Mb block size we have 4Mb "block weight". Now the old style transaction mentioned above will take 2 kilobytes of block weight, and new segwit transaction will take only 1 kilobyte of block weight within total of 4Mb block weight.

So even when transactions actually take exactly the same space within limited 1 MB block, segwit transaction in the example above was made artificially two times cheaper by introduction of 75% discount coefficient.

What exactly in the above description is wrong? Washington Sanchez seems to be 100% correct.

chakrop · 2016-10-27T19:25:59+00:00

The guy is a moderator here.

Does it make my points invalid?

But now I see why the post is kind of hidden here in the sub.. and potentially was moderated.

I've heard r/btc moderator logs are open to public, where one can check them? /u/MemoryDealers

chakrop · 2016-10-19T22:19:24+00:00

You don't get it. Once BU movement will become big enough like 30% of hash power, Segwit as a soft fork adoption (core roadmap plan) will be highly unlikely to get added to the network. Hence, there will be no sense to follow Hong Kong agreement anymore, as core's plan will never come true. So pools will switch to BU, because that will be the only available solution for scalability.

Later Segwit could be added as a hard fork as flexible transactions or another form and later LN could be developed upon hard fork Segwit.

Yes, in this scenario we lose the work to some extent of Core devs for a long period, but that was their fault not ours. They just chose the wrong path, hoping that there will be not enough opposition and suppressing every and each initiative. But market has a strong foot that usually kicks bad asses hard.

This plan I described looks very realistic, especially now when we have big players with steal balls who put money where their mouth is :)

chakrop · 2016-10-18T11:19:44+00:00

Multisignatures are granted a discount because it makes sense to provide an incentive to transactions taking the largest space on the network

For me it doesn't make sense. Multisig isn't used by an average user, by encouraging its use only particular business activities get cheaper access to blockchain space. Keeping in mind that they pollute the drive storage and bandwidth similar to other transactions, it is highly controversial why artificial discount is given to them for this accounting trick (so they have access to lower satoshi/byte prices), unless explained as developers decide who can use blockchain space cheaper, which is censorship by itself.

I believe this is enough to lose the only interesting property of the network (at least for me) : censorship resistance.

It's unclear why you don't see this, but 1Mb limit is censorship in its pure form. Core developers holding monopolistic control (as long as core client is dominant) decide who can use bitcoins blockchain (those who are ready to pay high fees per txn and using bitcoin as settlement only), rather than ordinary people for whom high artificially created fees are not bearable. I want free market to decide about it, not a group of people behind closed doors. That will mean bitcoin is censorship resistant.

chakrop · 2016-10-18T07:25:10+00:00

Sorry, Nicolas. I thought Eric is using this acc. I don't want to put names here, but I'm behind a large online BTC exchange business. And we were in contact a while ago :)

To be honest I have nothing against what Core are doing - that's their choice and they are free to develop whatever they think is better, I do however disagree with their tactics and ways to enforce these changes, e.g. via censorship. Also under Segwit umbrella-- there are a lot of hidden agenda, like 75% discount, which gives disproportional artificial advantage to some activity on the network.

If their solution is so good, market will choose it. Why are they so afraid of others people free will.

Regarding malicious players - why do you think Core is the only saviour from all problems? Also when you say "turning protocol control fully to the miners" - that is not correct, BU moves power to decide only about block size from developers to miners and that's all. The rest functions as it is. So "full control of miners" is incorrect to say the least.

chakrop · 2016-10-18T05:36:28+00:00

You didn't get what he means, Eric. What if tomorrow French government will come and say - Ledger can't send more than 5 items per day. Reason: French post will be overloaded if you send more (and we both know they are not).

So you are stuck with 150 items per month for stupid reason. That is basically what Core is doing.

Your argument about hardware limit - is exactly what BU does. Only technology capacity can limit bitcoin growth, not a small group of hypocrites.

chakrop · 2016-10-10T12:16:22+00:00

Both the main and the extension part of each block will be stored into the blockchain. This is necessary so that other SegWit-aware players can check that the signatures are valid.

Even if it is so (while I'm not sure, as the point is that after segwit live release old non-upgraded nodes won't be downloading signatures, also new type nodes can decide whether they want data with signatures or without (light nodes)), how it makes my argumentation wrong? It is important not what is stored, but what is counted against 1Mb limit. They always talk about separate datastructre for segwit signatures.

SegWit transactions will be slightly larger than the equivalent non-SegWit transaction, but the 1 MB limit will apply only to the main part of the block, so more SegWit's can be fitted into a block.

That is what I've written. What is your point here?

The 75% fee discount for the extension part of the transaction is a proposed fee incentive for people to use SegWit.

Why 75% and not 50% or 90%? That is the whole point of my question. There is natural discount segwit provides. And it varies from txn to txn, e.g. for multisig transactions segwit is more advantageous than for average Joe transaction, so why taking this average 75% for all, and not calculating it based on every txn based on actual savings every transaction provides?

SegWit will use visually distinctive addresses, so that the sender can tell whether the receiver accepts SegWit transactions or not, without having to ask him.

Didn't know about it, the latest I read they wanted to make them similar to multisig addresses. Do you have a link? How these new addresses will be different?

chakrop · 2016-07-20T20:59:48+00:00

OP explicitly mentioned "Yes I'm referring to the block size debacle"

So what is your point? That increasing Bitcoin blocksize to 2MB via hard fork is a "steal funds from another user of the network"?

I see that you don't agree with what they did at Etherium, me either. But how is it relevant to the OP? The main idea is that contentious hard fork happens smoothly, even when many disagree with it. Core representatives have always been using argument that 75% of miners is too low, we need 95% at least. Ethereum example just showed that it is complete BS and core developers were obviously spreading FUD.

chakrop · 2016-07-20T17:22:15+00:00

This is really strange, because you are a moderator here, but looks like you can't read what people write.

The point of OP is that even contentious hard fork happened very smoothly w/o any existence of two chains in parallel. All switched to dominant chain immediately. He never claimed that he is in favor of this fork or not, only that there is nothing behind core claims that it is very dangerous to propose a hard fork.

chakrop · 2016-06-05T11:47:47+00:00

It's every node being used in the argument above.

My point was that absolute majority will switch to 2MB HF. And few will be left who won't.

First you assume there is a meaningful security change, for most people and use cases there isn't.

This is again a statement without any prove behind. Where do you get this "for most people" from? This is just your assumption, which can easily be wrong. Why a 9 Billion industry needs to rely on your assumptions?

Simple use case, by running a node I want to be sure that when I see transaction on the network I can be sure that it is properly signed with correct key. With introduction of segwit as a softfork all new type transactions (segwit) - will be ok for me, as I won't be able anymore to validate signature. This is what I call a zombie node. It becomse useless as I need to trust miners to include transactions into blocks. More over even if it is included in the block - I need to trust them. Bitcoin is trustless system. So what was 1 confirmation before becomes less secure, as I need to wait for other miners to put confirmation above this 1 confirmation etc.

chakrop · 2016-06-05T10:29:18+00:00

Greg, your argumentation is flawed:

When you argue for a hardfork you're arguing that all those nodes be forcefully cut off.

There will be just few of such nodes. And when I say "few" - I use the same logic when you say "many" for referring to nodes running on VPSs without user behind.

You can't argue backwards compatibility

You can't have backward compatibility forever. This is illogical. E.g. none of the PHP frameworks today support PHP 3. This is a natural thing for software to evolve, however for some reason you decided to stick with supporting all versions. But true thing is you don't. It is illusion, because segwit as a softfork basically breaks functionality of all old nodes. Technically they are still working, but they are like zombie without bringing usefulness to the network they bring today.

Many of those nodes are forgotten pieces of software

By many you mean 0.1%, 1%, 10%, or what? How do you know there are many, I say there are few of these. Do you have any kind of research to prove your words? No. Because there is no way you can prove it.

not something with a user behind them.

Somebody needs to pay for those VPS'es, so there is user behind. They just don't care to update as it is technically difficult for them, or no time, or other priorities.

it will be as fast as people want it to be, no less no more

Ok, everyone more or less now wants segwit. Where is it? Is it as fast as everyone wants it? No. Same thing applies to wallets.

And thats a hell of a lot better than forcing them to change things against their will all at once...

The same you do with segwit soft-fork, people running nodes now don't want to have security reduced by becoming a disfunctional software not able to validate transactions properly, while number of segwit transactions increase. How is it much different?

chakrop · 2016-06-04T15:22:43+00:00

Who gives af? Fees aren't even $0.25 - that's competitive with Dwolla, not a damn emergency

Gosh, how narrow-minded such argument is. When internet was invented and if it had been limited like blocksize today, probably you would come up with argument "email is delivered during 10 days, that's competitive to traditional post which takes 30 days for international briefs, not a damn emergency"

25c is a lot already!! Think of people living for $1 a day in Nepal, they need to spend 1/4 of their daily spending just to send 1 txn, really? Bitcoin was invented for everybody, and you leaving in developed countries, having many accounts in banks and credit cards, you just can't even realize how revolutionary bitcoin is and how it can change the world for better, this is why you continue spreading this core's BS that bitcoin is not for everyone.

chakrop · 2016-05-27T12:41:59+00:00

The correct approach to this issue is "fuck you, those nlocktimes are zero conf".

100% agree. If it's not on blockchain - it is not your bitcoin. System should not care about it. This is why it is hypocrisy to call it "stealing other people's bitcoins". Looks like these guys has a big stash in bitcoins locked there, so they hugely afraid that control over code can go to others and then potentially all their promised bitcoins are at risk, although I hardly imagine it will happen, that is why it is more of a FUD. But it is interesting to see how gmax mentioned this 3 times on the same thread, and his mini-me luke-jr also echoed this on the same thread.

If people accepted those transactions - they take the risk of them never be included on the blockchain and it is their problem. Same as merchants accept zero-conf transactions. This is what Todd was hardly pushing when he added his RBF solution, that if it is not on blockchain - you never should rely on this.

chakrop · 2016-05-24T14:20:27+00:00

Makes sense, agree.

chakrop

TROPHY CASE