Bitcoin AVF, a full fork project for escaping segwit and 1 MB blocksize limit

[steffen]

It seems to me we are getting almost nowhere if we continue insisting that we should have the majority of miners backing us before we can move forward. The majority could easily be stupid, corrupted and/or owned by the powers that be.

Bitcoin Core / Blockstream claim segregated witness (segwit) and a 1 MB block size limit is necessary to scale bitcoin safely. I say that is BS. Massive evidence is piling up that these people are very technically skilled but dishonest people who want to deliberately undermine the security model Satoshi Nakamoto created. Even if segwit in theory could be used to accomplish something good that doesn't matter. What matters is that segwit can be used for something bad, ie undermining the traditional security model of bitcoin to turn it into a defunct settlement layer with centralised, expensive and otherwise destructive solutions built on top. The segwit initiative and the 1 MB block size limit should in my view be regarded as attacks on bitcoin. We should treat them as viruses. I therefore propose Bitcoin Anti Virus Fork (AVF).

I am not a software developer but I suppose it must be possible to create software which can detect segwit transactions and refuse to accept such transactions just like anti virus software has a collection of signatures for know viruses and can refuse such software access to computer resources.

Here is more specific what I propose if a "vaccination" against segwit can be developed:

I suggest "we" (yes, I know it means you) create a solution which will allow for a fork away from the present Bitcoin Core influenced bitcoin even though we are initially only supported by a minority of hashing power. When we have sufficient support (fx 50 out of the previous 500 mined blocks = 10% support for this Anti Virus Fork) the decision to switch away from the traditional bitcoin network and form a new network, the Bitcoin AVF network is triggered. 10% is not a lot but I suppose it should be plenty to provide the necessary hashing power to support a new well functioning bitcoin AVF network with good enough security. I suggest a 14 days grace period from the decision is triggered to the new rules start being used.

How:
Implement in Bitcoin Unlimited the ability to detect the use of Segwit in a transaction.
Implement that the Bitcoin Unlimited software can listen on two network ports, tcp port 8333 (for backward compatibility with the 1 MB limited bitcoin network) and one specific new tcp port for when the fork goes into production. Only one port, the new port, is used after the switch is completed.

During those 14 days these things need to happen:

• If it hasn't happened already the AVF supporting node owners must make sure their nodes can also listen on the new port besides port 8333. An easy method (a button somewhere?) to test the required network connectivity would be good.
• Users supporting this vision without segwit and without a 1 MB block size limit send their bitcoins to a wallet supporting Bitcoin AVF. If they don't, their bitcoin will remain the old kind of bitcoin only living within the 1 MB block size limited network. Sending your bitcoins to the wallet in Bitcoin Unlimited AVF should of course mean your bitcoins will become the new kind of bitcoin, bitcoin AVF.
• The remaining <90% of mining power have this time to change their mind and switch to the Anti Virus Fork software if they want to. Or they can do it later if they prefer.

When the 14 days have passed the AVF-supporting nodes:

• Recalculate the new difficulty based on say the proportion of the last 100 blocks which signal support for AVF.
• Can produce and will accept blocks larger than 1 MB
• Will not accept any blocks or transactions using segwit
• Will insist that the first block on the new Bitcoin AVF chain is >1 MB so all the small block miners cannot mine on this new chain.

Would such a proposal create a good solution to the present mess?

Wouldn't it provide good options for both users and minority miners who want to get rid of Core?

And how big a proportion of all outstanding coins do you think would be moved to the new unlimited AVF space during the 14 days grace period? 50%?

A benefit of this solution is that it is the users and miners who have taken the time to understand the benefits of big blocks who become the biggest winners.

Please comment.

 

[largerblocks]

It is going to be very unlikely to get 10% of the miners to agree to either tag support for this, or follow a 10% minority branch. Not even 5% are supporting Classic yet and that is a smooth bump to 2MB.

 

[steffen]

Largerblocks wrote:

It is going to be very unlikely to get 10% of the miners to agree to either tag support for this, or follow a 10% minority branch. Not even 5% are supporting Classic yet and that is a smooth bump to 2MB.

@largerblocks
That may be true but on the other hand pools like Antpool may prefer 2 MB blocks but will not mine for 2 MB blocks yet because there is too far distance between the present <4% support up to the 75% trigger threshold. They may want more pools to go first before they also hop on board. If the trigger threshold is much lower, like my suggested 10% or even lower, the finishing line seems easily reachable and they might be more inclined to tag support. Do you think a lower threshold (how much?) would be a solution or would you suggest just announcing that such a project starts from block xxxx.

I think that just announcing the project will create less media attention which is bad. Media attention will make users aware of the project which is important for two reasons:

1. Significant backing from day 1 reduces the risk of being ddos'ed to death in the startup phase and
2. Users need to make the decision about what chain they want to be on. If only few people hear about the project before a decision needs to be made the whole project will by a majority of bitcoin users be considered more like a scam, like pre-mining. That will lead to reduced support by all the parties we need to join (exchanges, users, payment companies, merchants).

Do you like the two anti virus vaccination ideas?

• The first block when going into production has to be >1 MB and
• Segwit transactions can be detected and will be rejected

I think the anti virus vaccination ideas serve two purposes:

• They force the old and the new chain apart
• They probably prevent future 51% attacks using the methods of 1 MB block size limit and segwit.

Agree?

 

[freetrader]

My opinion is : I am only against a soft-fork SegWit being forced in.

Hard forks such as @rocks ' satoshisbitcoin already fork away to a different block version - they would not be compatible with the soft-forked SegWit that BS/Core is planning to roll out. Core would have to rebase SegWit onto satoshisbitcoin's 0.11.2-based fork to endanger such a fork.

That suggests that a specific "AVF" is not really needed - as long as we strengthen and defend the already planned fork(s).

Regardless, I am with @steffen that we need to protect forks away from BS against the soft-fork craziness. SegWit on such forks may be useful later, but imho only as a HF, on wider community terms (i.e. sensibly implemented).

Am I wrong in my line of thinking?

 

[VeritasSapere]

It seems like the project that is being run parallel to Satoshi's Bitcoin can fit some of your objectives, we might as well work together. We also want to keep the PoW algorithm, and I certainly do not not like many aspects of SegWit, however I would not be against a simplified version of segwit, like the Classic development team suggested, when they have released it. That version would not include the specific transaction discounts many of us here are against.