Пассивные методы выявления нелегальной терминации трафика.
https://habrahabr.ru/post/320716/

I agree. It's a good summary.

I think the best solution in this situation would be Core to support Segwit2MB.

Do core devs say that there are many desired improvements that need to be packaged together to do a HF once instead of several times? I think most people would understand that. Ask for reasonable amount of additional time to do that. Cannot be It's not negotiable.

Is 2MB base size slightly more than Bitcoin needs right now? Maybe so. But should adoption grow, Bitcoin will need it anyway.

Are we afraid of 8MB total size blocks? I don't think so. Even with transactions backlog like now, most of time we won't be having 8MB blocks, more likely most of blocks will be about 4MB. Even if increased storage, bandwidth requirements will force some people to give up their full nodes, small decline in full nodes count isn't critical. Moreover, increased adoption may result in increased number of people interested in running full nodes.

So what's the point in refusing the 2MB HF and pushing the UASF? To teach miners a lesson? Maybe they deserve it. But it's unwise, immature. Even if they are so, does that mean that we should be like them?

If Core accepts the 2MB HF (not just plain blocksize increase, but combined with all desired improvements, properly scheduled), Segwit will most likely be activated sooner than with BIP148, in more reliable, civil way.

Why so? A link?
To me it looked quite simple:

How about CoinJoin transactions? Is there a way to replace such transactions with tree structures of transactions in a safe, trustless way? And wouldn't a tree structure be larger than equivalent single many-inputs-many-outputs tx?

Solution is pretty trivial:

С учетом рекомендации Минфина: рассматривать биткоин как иностранную валюту: https://vc.ru/n/minfin-bitcoin-foreign
будет уместно считать, что код дохода 2900 (доходы полученные от операций с иностранной валютой), налог 13%. Наверное, можно еще считать ценной бумагой, но ставка налога от этого не меняется, также 13%.

Дня 3 назад инициировал вывод долларов вайр трасфером с биржи Bitstamp на свой счет в одном из банков РФ (да, планирую заплатить с этих денег налог). Биржа перевод отправила. Сегодня с удивлением обнаружил, что биржа снова заблокирована. Допустим, эти деньги до моего счета дойдут, а в межбанковском переводе указано, откуда он. Допустим я ещё раз выведу оттуда фиат, с уже заблокированной биржи, тем же способом, и этот фиат тоже дойдёт. Чем это может мне грозить когда буду отчитываться (в декларации указывается на какой бирже была наторгована прибыль). Чем это может грозить вообще?

I'm aware of his position, but we also know that Luke is certainly familiar with current situation, and proposing something that has no even remote chance of being accepted, especially in the context of fulfilling such important, unique in it's kind agreement is for lulz at best. How big blockers should perceive this? They thought they are dealing with serious people and got such mockery instead.

Big blockers want 2MB base size. If we think that 8MB max total size is too much, it's possible to adjust parameters to decrease it to 4MB according to the agreement.

Then help Sergio to integrate all desired improvements. Announce that we are working on a hardfork which includes increasing base blockse to 2MB and a number of other improvements. Apologize for being late with that.

What do we want? To prove to our opponents that our point of view is the only right one? Or to finally scale?

I guess Luke likes to shock others, he himself couldn't seriously expect such proposal to be accepted. Nowhere in the agreement it is stated when actual blocksize increase must happen. He exploited this uncertainty to pervert the meaning just for lulz. If we are playing such games, soon we will need teams of lawyers and our agreements will become tens of pages in thickness.
On the other hand Sergio's proposal follows the spirit of the agreement. It is simple, honest, it gives each side what they want.

What proposal are you talking about? The one which proposes to shrink blocks to ~300kB or to keep them at 1MB for 7 years?

OK, I understand, core devs are numerous. It's nearly impossible even to gather all of them in one meeing. So how one could negotiate with them? Saying that they were not represented at the meeting is an excuse for doing nothing. I'd say that there were enough influential, prominent devs there to properly represent their party and make the agreement meaningful.

OK, if we read the agreement carefully, it's not very binding. Core contributors present at the meeting must only recommend a hardfork. And miners must run segwit in production only after hardfork is released in a version of Bitcoin Core. But we all know what both parties want: one party wants segwit, another party wants capacity of about 2MB for non-witness data. And I personally think, that it's far better to try come to already specified compromise than to do something potentially destructive such as UASF or to do nothing engage in trolling while observing how Bitcoin looses it's leadership, network effect, etc. And if something like Segwit2MB is released and miners still don't adopt it (what I doubt), then we can lay the blame on them and start preparing for a UASF of some kind.

But currently he's apparently the only one among segwit supporters who tries to resolve the conflict in conformity with the agreement.

I'm not surprised. So it looks like Segwit2MB is the only proposal up to now, fulfilling the Hong Kong agreement from devs side.

Proof?


Segwit and blocksize increase aren't mutually exclusive. In Feb 2016 they signed this:

Recently I took a look at bitcoin-dev mailing list, mostly to check reaction for Sergio Lerner's Segwit2MB proposal. The reaction was mostly negative.

Then I took a look at some of proposals listed here, and found for example this:
So my question is: which blocksize related hardfork proposal has most support from core developers?
Also, I would like to remind that some of miners who are currently blocking segwit, explicitly stated, that they won't run segwit without blocksize increase.

I don't see obvious holes/abuses with this approach.
However, it would only incentivize miners to change their BIP 9 flags when proportion of blocks signalling certain flag is significantly less than proportion of transactions demanding that flag. For example, miners would be incentivized to signal BIP_N if 70% of txes demand BIP_N, but only 30% of blocks signal it. Now if 90% of hashpower started to signal BIP_N, but 30% of txes demand BIP_M, miners will be incentivized to switch signalling to BIP_M, until more or less ratio BIP_N_blocks/BIP_M_blocks = BIP_N_txes/BIP_M_txes.
Also, this approach wouldn't work without majority of users actively expressing their preference through their transactions, despite sometimes having to pay higher fees and experiencing additional delays in confirmation times. I guess majority of users would continue generating transactions of default type, because they care more about fees and confirmation time than about something they have only vague idea about. So most of time we probably will be having like 90% default txes, 7% BIP_N txes, 3% BIP_M txes, what doesn't create any incentives to change signalling at all.
Nonetheless, in my opinion the idea is interesting.

Short answer: no it wasn't supposed to happen. At least it wasn't supposed to happen somehow automatically, without an intentional attack.

If short (more precisely: containing less accumulated PoW) chain is to be killed, then why iXcoin, I0Coin, NMC etc. chains weren't killed by BTC chain? Why ETC chain wasn't killed by ETH chain?

On topic. I think such attack won't happen anyway. After ETH/ETC split ETH had overwhelmingly more hashpower than ETC, they even created a special pool for a 51% attack, still they weren't successful. It seems to me people generally prefer not to engage in such malicious activities. Additionally, conducting such an attack could trigger PoW change in the attacked chain. That would render expensive mining equipment useless should market prefer the minority hashpower chain. If they abstain from attacking, they keep possibility to switch to the chain preferred by users.

I agree. I also thought about it. Even if one of this coins surpasses BTC in marketcap, their fiat (ETH), scam (DASH), centralised trusted (Ripple) nature will become evident sooner or later. Unlike you I also disrespect LTC since it's a copycat.

Nobody is going to change miners role. Their role is to provide consensus on the state of the ledger, on order of transactions.
Nobody is going to change the consensus mechanism. Chain with most accumulated PoW wins, provided that it's a valid chain.
PoW change is the last resort option, hopefully it won't be needed.
It's up to users to choose validity rules for blocks and transactions. It's that simple.

Yes, and this is one of possible ways to resist.