DRAFT Proposal: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split

[Robtcspierre]

TL;DR

Bitcoin is designed to probabilistically select one permanent choice amongst many.

Following this philosophy consequentially, a single Bitcoin chain, preserving the Bitcoin brand, can be achieved by making the extension of the SegWit2X chain conditional on the non-extension of the legacy chain, and vice versa.

This condition is fully symmetric. It means that the legacy chain XOR the SegWit2X chain will continue, but not both.

The proposal sketched out below, a pair of intrinsically coupled soft forks on both the 1x and the 2x chain, should allow this.

This idea is in draft stage and needs further input.

---

Overview

A lot of anxiety and confusion regarding the future direction of Bitcoin around the 2x fork date has appeared. The potential of a chain split and resulting chaos in the markets keeps coming up repeatedly.

In here, a comparatively simple change to the legacy ("1x") and SegWit2X (2x) chain is proposed that will solve this problem.

This change is a combination of two soft forks (one on each chain), meaning it will be backwards compatible with all existing clients, no matter on which chain they operate. As a soft fork, it is also an upgrade that solely concerns the Bitcoin miners, needing no further action on part of the users of any touched block chain.

This change will ensure a smooth transition through the 2x phase of SegWit2x and ensure just a single chain will emerge.

Principle

The change involves a deliberation of abandonment (DOA) chain, defined as follows:

This DOA is the chain of just block headers and coin base transactions, compatible with the legacy chain rules, starting at the 2x fork point (FP; starting at block height 494,784). All rules for difficulty and maximum cumulative difficulty and so forth are left unchanged and like on the legacy chain.

From the maximum difficulty DOA, a state flag "abandoned" (A) will be calculated, like this:

If the DOA is empty, A amounts to 'true'. If the DOA is non-empty, the coin base transactions and merkle roots in the DOA will be checked:

• if any transaction merkle roots in any of the DOA block headers indicate that more than just the coin base transaction would be in the merkle tree, A amounts to 'false'. (Requirement 1)

• likewise, if any coin base transaction in the DOA has more than one output or an output that does not follow a simple TBD "burn" pattern, A amounts to 'false' as well. (Requirement 2)

• if the above checks pass, A will be 'true'.

It should be noted here that the DOA chain of headers can not be confused with the 2x chain, as the 2x chain has a requirement of having a base block being truly bigger than 1000,000 bytes at the FP (wipeout protection), contradicting Requirement 1.

Requirement 2 is meant as further incentive for miners to consider the empty chain as abandoned.

To ensure a smooth transaction on the 2x chain, a soft fork rule is then added to that chain. It simply requires that the DOA criterion A, as defined above, evaluates to 'true'.

If the DOA criterion A for the maximum cumulative difficulty chain evaluates to 'false', a block on the 2x chain is to be considered invalid and orphaned.

Implementing this change on 2x will ensure that each miner is urged to create empty blocks on the legacy chain, assuming a simple 50% majority is willing to upgrade to SegWit2X at the FP. And if not, it will symmetrically cause all miners to stick with the legacy chain - and thus ensure a smooth, continuous operation in either case.

From the POV of both chains, this appears as a simple, respective soft fork.

It is compatible with all old legacy nodes and will cleanly signal that it is time to upgrade.

Protocol issues

On the network level, the change is conceptually simple. "block" messages will be accepted, both if they fulfill the "must be greater than 1MB" rule of the SegWit2X chain, as well as if they don't.

But in the latter case, the messages are added to the DOA chain, if the checks for proof of work on the block header pass. Extra data past the coin base transaction (potential transactions) on the DOA chain is thrown away, though impacts the calculation of flag A as noted above.

SegWit2X compatible clients will will forward both DOA blocks as well as regular blocks in "block" messages.

To ensure low orphan rate after this soft fork is enabled, good connectivity to both the 2x as well as the legacy chain is necessary.

Sunset clause

After 3 months, the requirement to keep track of the DOA chain will be dropped.

Activation

The soft forks in this proposal are to be considered active if the simple majority (>50%) of blocks from height 494352 .. 494783 have the uppercase string "B0RG" (like this, with a zero) anywhere in their coin base or by an activation through another, TBD mechanism.

This idea has also been posted to the SegWit2X mailing list (awaiting moderation) as well as a reddit discussion thread: https://www.reddit.com/r/btc/comments/775o5q/proposal_b0rg_bitcoin_zero_replay_guarantee

[christophebiocca]

If this hash is out of date (does not reflect the DOA chain tip).

What does "this hash" refer to? Not defined anywhere in the document.

[Robtcspierre]

@christophebiocca : Excellent point, this slipped through my last edit. I mean the block hash of the DOA chain tip with maximum difficulty. Fixed.

[Robtcspierre]

Interesting proposal, but should we really be helping to save the Legacy 1x chain and not focused on killing it?

But that's exactly the idea of this..? The idea is to make just one chain survive - the one with the majority of the hash power. That's why I wrote XOR above.

If SegWit2X does not have majority by fork activation, this proposal will then also ensure that no SegWit2X chain will be made - as all blocks are orphaned due to the DOA criterion being permanently false.

I feel that keeping Bitcoin in one piece is of utmost importance to its brand value. This avoids a potential war on the Bitcoin brand with two competing but viable forks.

EDIT: To answer your edit above:

Sounds positive, but I doubt Core would agree. Does this require implementation on the 1x side or can it work 2x only?

This is intrinsically coupled: You can only mine on the 2x chain (assuming the mining majority accepted the soft fork on the 2x chain), if you ensure that the 1x chain is not containing any valid or worthwhile transactions. The condition of 'not any valid or worthwhile transactions' on the 1x chain amounts to a soft fork to a block size of (basically) 0 as seen from the point of view of a "legacy node", in essence.

Assuming majority of hashpower behind SegWit2x at fork date, Core can, as far as I can see (but again, this is a draft and meant for further discussion) only circumvent this by introducing an incompatible change to their chain, such as demanding that a non-zero amount of transactions exists in each block. This will not be compatible with what SPV clients see as 'the valid chain' however, nor will this impact old clients - which will be urged to upgrade to a different chain (a Core fork or SegWit2X).

[JaredR26]

This seems like a fine idea from a purely technical perspective, but I can't imagine that the 1x miners & Core supporters would agree to it. If they didn't agree to it, it would just be an orphaned softfork and fail. Correct?

Is there a catching mechanism where the 2x DOA rules are not applied if the longest 1x chain does not apply the DOA rules?

[Robtcspierre]

This seems like a fine idea from a purely technical perspective, but I can't imagine that the 1x miners & Core supporters would agree to it. If they didn't agree to it, it would just be an orphaned softfork and fail. Correct?

Not quite. The coupling with 'no 2x extension unless 1x is stopped' through the 2x fork means that a simple majority of hash power decides on the 'empty blocks' soft fork on the 1x chain. And remember that a soft fork can asymptotically only fail if the majority of hash power does not agree with it.

Is there a catching mechanism where the 2x DOA rules are not applied if the longest 1x chain does not apply the DOA rules?

No. And that is the idea here: Ensure just a single coin. A single brand. Just Bitcoin. If the majority of hash power chickens out and goes back to 1x mining, then I think it is better if SegWit2X never came to be.

My proposal basically makes the direction that Bitcoin will be going a question of "simple majority of hashpower".

[JaredR26]

Oh, correction, are you saying that the miners clients will watch both chains and ensure that an empty-block chain is the second longest chain on the opposing fork(of the majority/true longest chain)?

That seems like a fine idea though complex to get implemented in time, could be managed by people this time and possibly added as a sort of hardfork locking mechanism for future upgrades?

The other thing is that I would expect the opposing side to simply softfork a rule that N blocks can't be empty in a row, or something like that. Or add a rule where empty blocks versus a full mempool will be considered non-standard and preferably orphaned. Also keeping the two networks connected would be difficult since 0.15.0 bans 2x and BU/classic/etc will be banned as soon as they relay invalid blocks/transactions.

Fundamentally the same thing can be done manually by miners, if that was a step they were willing to take, but the response would inevitably be a PoW change from Core. Which might be the most desirable outcome for everyone if we had a clean split.

[JaredR26]

If the majority of hash power chickens out and goes back to 1x mining, then I think it is better if SegWit2X never came to be.

I think even better than that would be that your proposal seems to require more than just a simple majority, it requires a supermajority. It has to be able to maintain two full majorities(67%+) of the hashrate if the empty-block chain is tied to the reverse of the longest chain, and not allowed to become longer than the longest chain. In that way the victor between the contention would need to be sufficient to maintain double the majority of the weaker chain. I'm not sure how things could be handled if neither side had this double-majority.

Sadly while this would solve the contentiousness from a technical perspective, it will not solve the legitimacy problems among the ecosystem and with neutral observers. As things stand today, Core has(and has had since August 2015) a serious psychological legitimacy problem, primarily driven by the censorship of /r/Bitcoin and sites owned by them and the HK agreement/forced segwit approach; That legitimacy will continue to cause problems for years if 2x fails. If 2x were to be totally successful, the legitimacy problems would simply be reversed and now be on this team and the miners/businesses. The community divisions will continue to plague everyone either way. Forcing a PoW change to give us a clean split between the ideologies might address this, but it also might not address this.

[Robtcspierre]

Oh, correction, are you saying that the miners clients will watch both chains and ensure that an empty-block chain is the second longest chain on the opposing fork(of the majority/true longest chain)?

Yes, essentially. Require that the longest chain on the respective other fork is empty. Exactly!

That seems like a fine idea though complex to get implemented in time, could be managed by people this time and possibly added as a sort of hardfork locking mechanism for future upgrades?

If this is generally positively received, I am willing to throw all my measly time until "the day" behind implementing this. I am not very familiar with the current code base, though. So this would likely need lots of developer resources from experienced people instead of myself.

This is also why I specified the DOA chain as above - by just checking a very boiled down rule set, yet completely compatible with the legacy chain (and this is extremely important to test, of course), it should be very doable without running two instances of 1x and 2x bitcoind in parallel, or similarly crazy approaches.

The other thing is that I would expect the opposing side to simply softfork a rule that N blocks can't be empty in a row, or something like that. Or add a rule where empty blocks versus a full mempool will be considered non-standard and preferably orphaned.

Also keeping the two networks connected would be difficult since 0.15.0 bans 2x and BU/classic/etc will be banned as soon as they relay invalid blocks/transactions.

Yes, good connectivity is important, but that is also true for Bitcoin in regular mode (without any controversiality). I think it will be almost impossible to isolate the two networks so far from each other that the DOA info will not cross-flow. If you are a miner, I see a very easy set up that will allow you to bridge Core and 2X and make sure that the DOA flows in both directions: Set up a Core node and connect it to the wider Core network - and then also connect that node to your 2X node. As you are in control of both nodes, you can thus prevent the Core node from disconnecting (and if Core has implemented a 2x detection recently, simply use an older Core node).

Forcing a PoW change to give us a clean split between the ideologies might address this, and it also might not address this.

Yes, excellent points, this is not a panacea against all propaganda. If the majority of miners implement this, it will force Core's hand however, as I don't see (assuming HP majority) them not implementing a counter "UASF" or POW fork to this. But this is politics and kind of off-topic.

In the end, and as this is a soft fork, it is up to the miners to evaluate this and also the political angle and decide on the merits of going with a technical solution to ensure just a single SHA256 Bitcoin chain - or not.

EDIT: I disagree on anything than a 50% threshold for this simple reason: If a set of voters have to decide on a binary issue (like it is in anything Bitcoin), a simple 50% majority will always ensure some outcome. When requiring any majority that isn't 50%, this isn't the case. Higher thresholds usually amount to a form of "gentlemen rules" anyways, and for example a majority orphaning players that keep such a gentlemen threshold from reached can bring the threshold back down to 50% in either case.

It should further be noted that the current times seem definitely not good times for any extra gentlemen rules in Bitcoin. The maximum cumulative difficulty chain requirement should suffice.

[christophebiocca]

This doesn't have a stable equilibrium. Each miner can choose to do one of the following:

1. Mine the DOA chain when it is not long enough, mine 2x the rest of the time. Revenue is scaled by 1 - 2*L where L is the legacy-supporting hashpower.
2. Mine 2x constantly, publish the blocks whenever the DOA chain is long enough (or don't even check and try publishing the blocks constantly). Revenue stays the same and someone else eats the cost.
3. Mine the legacy chain.

Miners supporting the 2x chain thus face a prisoner's dilemma. Miners supporting the 1x chain can mine the 2x chain constantly and, whenever it is valid, sell the proceeds to finance mining on the 1x chain.

It also doesn't provide for any measure of usability of the 2x chain during this transition. A 60/40 split results in 1/5 the usual block production rate on 2x and 2/5 tx capacity of the pre-split chain, at best.

Moreover this can be defeated by a simple soft-fork requirement that's mutually incompatible with the DOA rules, or just by waiting for the sunset clause to kick in.

[JaredR26]

Mine the DOA chain when it is not long enough, mine 2x the rest of the time.

Exactly how the hashpower is split can be resolved with some coordination between the miners. The important part is to ensure that the DOA chain is the longest legacy chain if and only if the 2x chain is the longest chain. The DOA chain wouldn't have to be maintained for very long, this would result in a far stronger response from users and markets.

But I have another idea, one that originated from someone else after reading this proposal. An alternative variation of this idea would be for the miners to apply a soft-fork special logic to the 1x chain. They could orphan any blocks that open a new segwit utxo, essentially turning off Segwit. This is perfectly within the terms of the segwit2x agreement, and would require the same majority on the 1x chain as the zero-block approach.

This has the added advantage that if the 2x fork is not successful, the code to turn off segwit until the compromise can be fulfilled would already be written. This isn't a great step for the ecosystem, but it is much less bad than allowing a vocal minority to activate segwit through trickery and continue to block the progress of the ecosystem.

Thoughts on this? Both variations could actually be written - The segwit-stalling code as a safety net against breaks in the segwit2x compromise agreement, and the XOR one-chain guarantee approach as an option that miners could engage if they favored that approach to the problem.

[Robtcspierre]

@christophebiocca : Hmm, on 1. and 2., I would object that a miner would withhold the 1x block until he finds a 2x block and then sends them both into their respective networks. Which makes 2. nearly a non-option.

Miners supporting the 1x chain can mine the 2x chain constantly and, whenever it is valid, sell the proceeds to finance mining on the 1x chain.

But this is completely symmetric, isn't it? Replace "1" with "2" here and it should stay true as well?

It also doesn't provide for any measure of usability of the 2x chain during this transition. A 60/40 split results in 1/5 the usual block production rate on 2x and 2/5 tx capacity of the pre-split chain.

Agreed, but I don't see how this condition can prevail for long. And with that kind of split ratio, usability will be bad in any case.

Moreover this can be defeated by a simple soft-fork requirement that's mutually incompatible with the DOA rules,

Yes - but the soft fork will only concern nodes that implement it - all other nodes will follow the longest chain with the legacy rules!

or just by waiting for the sunset clause to kick in.

Yes, but it appears to me that 3 months is sufficient time for a clear winner to emerge on who will own the name Bitcoin.

[JaredR26]

I would object that a miner would withhold the 1x block until he finds a 2x block

That would cause heavy orphaning and wasted hashpower. But there's definitely something can can be done there to keep the empty chain as the longest chain.

[christophebiocca]

I would object that a miner would withhold the 1x block until he finds a 2x block.

Miner A pursues the strategy you outline, while Miner B mines only on the 2x chain.

If they have the same hashrate then Miner A has 1 block on each, while Miner B has 2 blocks on the 2x chain. At best the revenue ratio is 2:1 in favor of miner B. At worst Miner B made their blocks with no knowledge of Miner A's one block (because it was withheld) and so ends up orphaning it.

Plus by withholding the DOA blocks until a 2x block is ready, the miners are effectively no longer cooperating on building the DOA chain at all. They will lose unless the single biggest miner on the 2x side has more hashpower than all other miners put together on the other side.

[JaredR26]

At best the revenue ratio is 2:1 in favor of miner B.

Miner A could apply soft orphaning penalties to miner B unless they see active PoW on the 1x chain. I think this is a part of what @Robtcspierre is proposing that he would write. I don't think this is doable with the "withholding blocks" idea due to the costs and the issue you described at the end there, but it is doable with various other types of coordination. Ultimately it does come back to miners working together and holding to the agreement; One miner couldn't succeed at this alone.

[BTCgithub]

Another thing to consider with 51% attacks/empty blocks is that they accelerate the Difficulty Reduction for the 1x Legacy Minority chain.

[satoshisSockpuppet]

The good thing about this proposal is, that I think Core will stand behind it as well. It unifies the community again! It matches core's criteria for a safe update:

• Soft fork (backwards compatible, no node upgrades necessary)
• No signalling period by miners (deemed unsafe by core devs now, e.g. Lombrozo), it's a user activated soft fork
• It enhances decentralization by reducing the operating cost for a full node to nearly zero!
• It demands full focus on 2nd layer solutions.

[Robtcspierre]

@christophebiocca : I now see what you are saying, thank you! That instability on the 2x chain could be avoided by rewarding the DOA miners half of the next block reward on 2x, couldn't it? (Potentially weighted by (DOA difficulty)/(DOA difficulty+2x difficulty) )

That also seems doable as a soft fork, it would be more complex, though. If you don't think that is a viable way to deal with it, please tell me.

Other than that and to reiterate, I think your objections regarding selling a fork get solved with the either-or of the situation. They all appear symmetrical.

@BTCgithub: My proposal is just making defense against a legacy chain mandatory. It would extend the chain only if someone attempts to mine on it. If no one mines on it, no extension.

I would expect a proposal like B0RG to be a strong deterrent to mining on the legacy chain to begin with (assuming majority hash power behind SegWit2X), so I would thus also not expect many or even any blocks on it. If the legacy miners expect that the majority will mine SegWit2X, they'll rather want to join 2x.

And again - it applies the other way around as well: If miners collectively expect mining to happen on 1x, no one will dare to mine 2x.

[hardforkmatters]

B0RG proposal is GREAT! My small idea is HOW to get the code for it within TEN days: lets do ICO from most valuable man of us (Mr.Garzik) without hard cap to get funds for fast & perfect coding. 33% of funds to write new code. 33% for test code of previous 33% percents. 33% for all scenarios calculations, Game theory analitics & etc. Why not? BIG money (after ICO) will send a message to all markets about real POWER. Must be even a SWIFT account to receive funds - just to understend support level in non-blockchain world (don't you smile).

[limopc]

Hi,

Hope you guys do a great job as always.

I am not that techie but as a user, I have to contribute my 2 cents.

Anything and everything should be done to ensure the following: 1- users having BTC now should keep having BTC and not losing any. 2- “BTC” and “Bitcoin” are brand names and “property” of core, and holders, the brand name has value by it’s own. So, we need to ensure that no matter what exchange, what wallet, what miner, what other blockchains ... calls the other crypto or label it as BTC or Bitcoin should not be able to do so, be banned, kicked out from communicating within “our” network...

If one network should go away I believe it is the other network, because to my simple understanding, they already have premined coins, and they want simply to “hijack” the value of BTC and copy it to their new crypto, ...

Just my own point of view.

I hope I didn’t bother you.

[kek-coin]

Just want to make sure I'm grokking this right. This is kinda like a fancy empty-block attack on the original chain that adds in the additional requirement that B2X has significantly more than 2/3 of the hashrate to counter vulnerability to variance. Is that correct?

My reasoning: if exactly 2/3 hashrate is pro-B2X and 1/3 is honest-mining BTC, then the B2X hashrate would be split 1/3 to mining empty blocks on BTC to overtake the honest mining and 1/3 honest-mining B2X. Seems like an expensive joke if the price disparity of the B2X/BTC futures contracts on the exchanges are any predictor.

[ThermosCoin]

A chain with nothing but empty blocks isn't going to get a price. Even under Bitfinex's terms the B1x token would become worthless, "reorg or technical issue". This provides a guaranteed way for a supermajority to ensure there is only a single chain. And since everyone wants a single chain outcome, that seems like a win for everyone.

[ebliever]

This is an awesome tool for forcing the Bitcoin community to come to grips with a mining cartel that is power-mad and avaricious. The obvious outcome if miners adopt this will be a PoW change (and policy of more in the same in the future as needed) to break the power of the cartel forever. Thank you for developing it!

[ThermosCoin]

This is an awesome tool for forcing the Bitcoin community to come to grips with a developer cartel that is power-mad and avaricious. The obvious outcome if community adopts this will be a ragequit (and policy of more ragequits in the future as needed) to break the community into fragments forever. Thank you for developing it!

FTFY

[ebliever]

The market has made it clear whose side they are on. Go ahead, make our day.

[KyrosKrane]

I'm thinking for this proposal to work, there has to be some link between a block mined on the majority chain (chain M) and the tip of the DOA chain (chain D). My thought is something like this. In the coinbase message of any block mined on chain M, there must be a reference to the tip of the chain on chain D. It can be the block height, the block hash, whatever is most convenient; so long as it's a standardized and recognizable format. When a client receives a new block announcement on chain M, it follows the following algorithm to determine whether the block is valid.

1) Does the block include a reference to the tip of chain D? If not, reject the received block. 2) Check the referenced block on chain D. Is it an empty block? If not, reject the received block. 3) Check the referenced block on chain D. Is it the tip of chain D as we are aware of it? If not, reject the received block. 4) Follow the existing rules on whether to accept or reject the received block on chain M.

This would account for @christophebiocca 's concerns about a selfish miner who continues to mine chain M when the tip of chain D is not empty, withholding the blocks until after another (honest) miner extends chain D with an empty block. If the selfish miner were to try broadcasting the withheld blocks after the tip of chain D has been extended, the blocks would no longer be valid (as the tip on chain D is no longer correct), and they would be rejected.

Note that this does not affect consensus once this proposal is sunset. The block would still be valid (after the sunset period) when steps 1-3 above are ignored.

[chelinho139]

What a stupid proposal...B2X will fail terrible. Good luck losing your money and time. cheers.

[kek-coin]

@KyrosKrane with your proposal the validity of a block would be dependent on the order in which you received blocks from two different blockchains, highly undeterministic.

[KyrosKrane]

@kek-coin I was trying to explain towards the end that my proposal doesn't affect consensus; it just affects whether the receiving client will build upon a forwarded block or not. The rejected block might be intrinsically valid; but it isn't counted because there is an external condition (chain D is not empty) that prevents accepting it and building on it. The client could add additional optimizations, such as rechecking a sent block that was previously rejected on chain M when a new block is mined and accepted on chain D. The purpose of my proposal was specifically to ensure that you couldn't do a block withholding attack on chain M while honest miners go and mine on chain D. I'm open to other suggestions or improvements.

[kek-coin]

It will still be consensus-critical during the 3 months before the sunset.

[limopc]

Just wondering, would the time stamp on a transaction for a specific public address help to distinguish and accept or reject the transaction?

I already have x BTC on this specific public address, it is recorded on the ledger and time stamped. Sending any amount out of this address requires validating on the blockchain (which have time stamps), so replaying occurs later, after the current transaction, so it can be rejected.

I’m not sure if I understand properly or expressed myself properly.

[lastbattle]

Silly proposal. Instead of embracing segwit as a second layer scaling, you guys are simply protecting your pride here with 2x part.

Segwit should have been activated right from the start if not for you all blocking it. Don’t blame the other side for not activating your 2x.

This repo is dead as far as I can see, only 1 silly dev holding the titanic deck up.

[limopc]

@eaxvac

Just to be sure I understand.

What you are saying is the B2X on mid November will be just the original BTC, 2MB will be it’s blocksize?

Just to be sure I am clear, I have nothing to do with politics, I only care about my money, about crypto growth and adoption..

[ThermosCoin]

@limopc yes, B2x will be the original BTC.

[limopc]

Thanks @ThermosCoin

Any risks of losing my current BTC?

It is currently on Jaxx, iOS Should I just keep it there? I hope you guide me. I’m not that techie with crypto. Thanks

[limopc]

Just enlighten me a bit about replay thing and... market price of this and that coin, how not to lose money (in USD terms in the end)

[ThermosCoin]

If you're a newbie and want to be safe, the safest thing to do is to leave your coins where they are for the duration of the fork. No matter which side comes out the victor, you will have them.

Attempting to split the coins and sell a portion amounts to making a bet on one side or the other, and will be a technical process whether replay protection is added or not. If you make the wrong bet, you have no more BTC. The safe thing to do is to leave them where they are. The fork event should be resolved soon enough.

[limopc]

Ok, so for now I should leave them as they are and not making any transaction or movement as I wrote at bitcointalk here https://bitcointalk.org/index.php?topic=2264088.msg23342509#msg23342509

Just want to be sure my understanding is correct. Please let me know.

If you can give me a github link to Segwit2x like this I will appreciate. I’d like to know more

[ThermosCoin]

This is the segwit2x github, here.

You are fine to make any transactions between now and Nov 12th. Sometime after that is when the fork will occur, right now November 16th it looks like. After that point, just plan on not making any transactions for about 30 days.

There's plenty of other things you CAN do safely during that period, but it would be unethical for anyone to recommend anything to someone who is uninformed of the situation or technicals/risks. If you want to do something else, become informed which will take a lot more reading than you might get here. Read or post on http://www.reddit.com/r/btc and take the answers you get with a grain of salt.

[limopc]

Thanks @ThermosCoin

I still hope to hear what you think about my analysis in the link I mentioned

Thanks

[ThermosCoin]

Transactions are not actually timestamped in Bitcoin. The closest thing is the nLockTime which means "don't include this transaction before \<blockheight>". That is indeed one of the methods of replay protection, by taking advantage of the fact that the 2x chain is likely to be much longer than the 1x chain.

Otherwise there is no way to say "only accept this transaction once." The two chains (1x and 2x) ignore eachother. To eachother those chains are invalid and might as well not exist.

[limopc]

Ouch... I thought there was some sort of time stamp by any means... maybe it should be considered somehow to be included in future releases, it might contribute to security and protection of the currency, using of course UTC to the smallest possible plus transaction ID.

[nshCore]

You people suggesting these attacks should be absolutely ashamed of yourself.

Having to plan black hat attacks against the core chain is not giving you consensus or a mandate to use the btc ticker!

Open software can be forked and new projects sprout from it, that is the great thing about FOSS, but ultimately it is down to the user which project/ coin/ chain they want to follow.

Co-ordinating attacks and colluding with miners to leverage users onto your chain and taking control of the ecosystem is disgusting, and shows that you have no concern for the end users only your own personal greed and vanity.

[nshCore]

@limopc this B2x coin will not be the original bitcoin as @ThermosCoin

@limopc yes, B2x will be the original BTC.

This is an altcoin trying to replace bitcoin, and has only come about because of corporate greed, anything you read here will be totally bias to their narrow minded opinion.

[hardforkmatters]

We need ICO to see actual support level! With a BIG money we can do it within TEN days (Crypto Crowd Coding - what can be better?))) CCC will save BTC

[limopc]

I believe “attacking” is immoral Any currency is backed by morals and ethics to have respect and therefore have value.

Think of fiat currency x of a country that is being just printed by central bank, or same currency that is just being counterfeit easily and counterfeit fiat is widespread, or even BTC when it was thought to be a currency of criminals.... what value does it retain?

Plus, if there is an attack, the public would think the attacker is evil, and the attacked is good/kind, and would be then supported.

Even if attack succeed, it will simply prove to the public that cryptos can be attecked and brought down, so, out of crypto in general, everybody loses, even the winning attacker.

Unless the attacker wants to make some quick huge money and convert to fiat and to hell with crypto... this is robbery... with all my respect. No offense.

I reconfirm, I am not into any kind of politics. It doesn’t interest me

[BTCgithub]

The entire point of Bitcoin is the Nakamoto Consensus for Miners to compete and vote on the direction that the decentralized network will upgrade.

The point behind Bitcoin is not a to have a small group of centralized/political Core developers playing Trollish games posting in public forums and playing politics. Vote with your Hashrate.

Free market competition (some would interpret as 'attacking') is the nature of Bitcoin. If your chain/coin has a weakness then it should be Upgraded and Fixed, not hidden and cried about.

[limopc]

@BTCgithub

Sure, competition is the key for success and survival. No discussion about it.

I was under impression that a technical attack (like breaking through a bank website) and draining money from it because of a security flaw or inefficiency, this is stealing, it does not give a reason for the robber. If you even “found” money in the street you should not take it anyway. This is the rejected attacking.

But If competing and introducing a better product is called an attack, it is more than welcome.

What’s important is it be a fair and ethical attack, competition I mean.

[ebliever]

Proposals like this deliberately avoid the free market competition of the marketplace, replacing it with decision-making by a handful of powerful miners. I've no problem with letting 1X and 2X compete in a free market. But imagining that the developer community is "centralized" and then immediately proposing a centralized solution of miner hegemony is extremely hypocritical. It will also fail for obvious reasons, just a question of how much economic damage will be done.

[BTCgithub]

Crying Trolls http://bashco.github.io/2x_Countdown/

[rfreemobile]

@BTCgithub

miners do not vote on anything, they are hired to do a job, not to redefine Bitcoin.