Can you confirm that your node banned its peers for relaying a too-small block? Run getpeerinfo and paste the output here if you can't interpret it?

I think it banned mostly nodes that were running slightly older versions like 1.14.1, or also my BU node (5.135.186.15). (because they kept extending on this chain without rejecting the block, the BU node is now on block 32826)

getpeerinfo: https://pastebin.com/Au8CDaDs

listbanned:

[
  {
    "address": "5.135.186.15/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "52.168.136.58/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "52.213.126.249/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "82.201.92.138/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "101.37.33.210/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "101.99.31.77/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "104.239.175.108/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "115.75.4.185/32",
    "banned_until": 1499722044,
    "ban_created": 1499635644,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "153.169.136.25/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "195.154.69.36/32",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }, 
  {
    "address": "2001:41d0:8:c30f::1/128",
    "banned_until": 1499722014,
    "ban_created": 1499635614,
    "ban_reason": "node misbehaving"
  }
]

It turns out the DOS-ban is intentional, unlike in the first draft of the hard-fork-on-block-X PR.

Given that, what you're seeing is the intentional outcome of wipeout protection, except that no blocks are being built by segwit2x nodes for the testnet. The chain is forked permanently (at least for 1MB nodes, BU might switch back and forth based on which chain is the longest).

Ok, so the code seems to work like it should. This is still a strange event,
I would have expected that the miners are prepared that this condition could happen,
so they would be ready to mine the >1MB block in time.

I guess a miner needs to create a big block now for the chain to continue...

On https://testnet5.blockchain.info/ it appears to be continuing to follow the fork with 1mb blocks while http://btcfaucet.ix28uktqsp.us-west-2.elasticbeanstalk.com/ (which I've compiled to be running the latest beta release) appears to be on the chain stuck on block 27070.

Assuming as @nomnombtc stated we're just waiting for a miner to create a single block > 1mb to continue this blockchain. I'm not sure what solution was selected to ensure we've got this covered when live - assuming we'll have enough of a backlog of transactions in the mempool doesn't seem like a reliable option.

How long has it been stuck? Is anybody actually mining 2x on testnet5?

There are transactions in the mempool and I'm assuming there are still miners on testnet5 - likely just waiting on enough transactions to occupy a > 1mb block.

Does anyone have mempool stats?

Should have used the hardfork bit instead of a hacky kludge 🙃

Have there seriously no miners or testers for the past nearly 24 hours!?

Should have used the hardfork bit instead of a hacky kludge

This is only a problem on testnet where there are not enough transactions to reach the limit easily without scripting spam.

And nobody planned on scripting spam (aka. testing)?

So basically, we're supposed to disregard this bad testing outcome [FAIL] because the test environment wasn't properly thought out?

Pay attention to the facts people. The non-segwit2x test chain was 5,697 blocks ahead 7 hours ago. Someone jumped on testnet with a modern ASIC miner under the non-segwit2x codebase and mined nearly 6000 blocks in less than 1 day. Someone is screwing with the chain intentionally before the devs intended to start the test.

So yes, you're supposed to disregard attacks that can't possibly happen on mainnet being done by trolls. Or you can just continue to attack the project for lulz, no one with any critical thinking skills is going to listen to you after looking at the facts.

So how are we going to test this under adversarial conditions? or do we conclude that "testing is impossible"?

So how are we going to test this under adversarial conditions? or do we conclude that "testing is impossible"?

Please describe an adversarial condition where the main blockchain could get 6,000 blocks (three difficulty changes) in a 24 hour period with an empty memory pool. After you do so, we can discuss how to test that situation.

lol, issues a 5 usd altcoin can overcome are too big for btc1

@GratefulTony once the first block of > 1mb is created the blockchain will continue as normal. What @JaredR26 stated makes perfect sense.

Why the delay in testing?

@jheathco

Adversarial conditions on mainnet will be entirely different when real money is on the line-- these kids are pulling your feathers for lulz--Don't expect reality to be any kinder than a test tube, even if this particular failure mode is unlikely.

My question is: what is the "Plan B" for testing this code?

@betawaffle

Why the delay in testing?

I'm not sure, as I'm not privy to the testing plan (and agree that that part should be more public and clear).

If you and @GratefulTony disagree that this scenario is not a feasible adversarial condition for mainnet, or disagree with my speculation on the cause of the issue, can you clarify why?

If instead either of you agree with my response that testing for adversarial conditions that cannot possibly occur on mainnet is not necessary, can you state so? There's so much anger and deceit in this debate - from every side - that a lack of clarity will only contribute to more anger and deceit in the future from at least one side of the debate. Fair?

@JaredR26

I'm trying to be as productive as possible here: what's plan B to test the code if testnet doesn't play nice? Get more real miners to mine testnet?

@JaredR26 I agree that's not an adversarial scenario for mainnet. The concern I have is this testing plan which AFAICT, either has no transactions, or hasn't started yet (which doesn't make much sense).

@GratefulTony No plan B is needed, Just one >1MB block once there is enough transactions to fill it. Worst case scenario on mainnet is that it will work as expected!

One could only conclude that the test so far is a success, S2x refuses blocks that is not >1MB when they need to be. Not enough transactions is an non issue on mainnet. The outcome will only be clear after the needed size of transactions has been reached.

My question is: what is the "Plan B" for testing this code?

I suspect the test will need to be restarted as the devs won't be able to see the effects of the split in real-time anymore. To prevent another attack they may need to plan a different testnet starting over with better parameters to get it done quickly / control when it activates. Unfortunately that testnet may need to be done in secret (Thanks anonymous attacker, you've done a great service here!).

I'm trying to be as productive as possible here: what's plan B to test the code if testnet doesn't play nice? Get more real miners to mine testnet?

You still didn't either agree with what I said, or state what part you disagreed with... Can you do that?

I don't think that adding miners to testnet is the solution, getting into a testnet arms race with anonymous attackers wouldn't be productive. I'm open to suggestions or maybe they will weigh in(I'm not privy to the actual plans), but the only ideas that come to mind initially would be tighter control over the activation process in testnet code and restarting, or a secret new testnet. Neither are great solutions.

@JaredR26 I agree that's not an adversarial scenario for mainnet. The concern I have is this testing plan which AFAICT, either has no transactions, or hasn't started yet (which doesn't make much sense).

Thank you for stating so. I agree that the lack of clarity around the testing plan isn't ideal. Unfortunately it may become more secret now to prevent a repeat of this from interfering with observations... Making it more open and still thorough within the time limit might be a harder path, sadly.

@JaredR26 You mean a private testnet? That will boost confidence, for sure.

@GratefulTony No plan B is needed, Just one >1MB block once there is enough transactions to fill it. Worst case scenario on mainnet is that it will work as expected!

I'm not sure that this is sufficient testing. I'd much rather be watching / debugging multiple nodes/screens at the moment of hardfork to see what happens, when, and to whom.

One could only conclude that the test so far is a success, S2x refuses blocks that is not >1MB when they need to be.

That's one test and one potential failure mechanism. I doubt it was intended, though, and it is quite far from a thorough test of the variety of outcomes.

As a bitcoin user, "trust us, we tested it" isn't going to fly.

@JaredR26 You mean a private testnet? That will boost confidence, for sure.

Agreed, not ideal. If we have better suggestions we should list them to help the plan. Maybe they could whitelist specific miners under their control on testnet? Wouldn't help though if the whitelist was public as the attacker could mine to the whitelisted targets.

As a bitcoin user, "trust us, we tested it" isn't going to fly.

Based on your statements, I don't think "segwit2x" would fly with you either, so that statement doesn't really mean anything. But I agree that openness would be better if at all possible, but openness would probably be worse than either missing deadlines significantly or poor testing if those were the only options.

@opetruzel it just needs to be 1 000 000 bytes which is the limit, adding block headers and coinbase and the block is > 1 000 000 bytes (that transaction already exists)

mempool will have the needed transactions, and if not it is easy for any miner to create them on their own (on mainnet)

Im sorry but i cannot participate any more with this project. I have come to the conclusion that the people involved do not devote enough time to consider the possible consequences of their actions to minimise risk.

This replay protection method is showing this. If testnet had not had this issue would there have been any debate? And what other areas of the code have been overlooked causing problems waiting to surface? Have a nice day, and good luck with the project. Here is hoping that you wont screw completely up. Good luck to whoever associates their name with this project.

The assumption that they will be available has already been shot-down as dangerous.

You find me the last time that Bitcoin couldn't come up with 1mb of transactions within 2 hours if the chain halted(mempool + transactions added). If you can find a time in the last 3 years where that happened, I'll change my opinion and support what you're saying. Short of that, its a ridiculous assertion to claim that transactions will just stop on Bitcoin suddenly.

@snavsenv

If testnet had not had this issue would there have been any debate?

That is what testnet is for, testing. In any case, as has been said severally, code worked as intended in an adversarial environment.

You all are missing the point.

Moreover, btc1 by default will not make a block >1MB even if there are transactions in the mempool for it. You guys are just making your code all the more frighting by vigorously denying the issues.

That's the real issue at hand with btc1 atm. Will the currently released btc1 code deployed on testnet5 actually ever build a > 1MB block and make progress?

Last post.

@pekatete do not expect me to believe devs were hoping someone would mine 6k blocks and trigger the hardfork bit. In fact someone was arguing they didnt. I think this supports my view that devs of the project do not devote an adequate amount of time and overlooks things as a result making the project too ambitious for its own and bitcoins good. Have a nice day.

@JaredR26 you just once again argued that past events are proof of future events. If you insist on perpetuating this flawed logic, then it's unlikely you have any desire to see the flaw in blindly expecting there is a mempool backlog some random time in the future or that enough people will risk their coins by transacting within the days of the hard-fork.

The only ridiculous asseration is from you by ignoring a real issue.

There is no good reason for testnet5 sw2x miners to be stuck at the hard-fork point... it is something that would be been trivial to prevent in the implementation, and at least 1 method has already been given that doesn't involve making tx just for the purpose.

That's the real issue at hand with btc1 atm. Will the currently released btc1 code deployed on testnet5 actually ever build a > 1MB block and make progress?

Following up here. 2mb fork seems stuck at block 27070 [1], and the 1mb fork has progressed to block 34931 [2].

That means there have been 7861 blocks where the 2mb hasn't been able to make any progress.

The minimum sized transaction during this period seems to be 0.29 kb [2]. Meaning that the 1mb fork has processed at least 2.2 MB of transactions since the 2mb fork became stuck.

It seems the 2mb fork is stuck until code changes are made? (or my math is wrong?)

1. http://btcfaucet.ix28uktqsp.us-west-2.elasticbeanstalk.com/
2. https://testnet5.blockchain.info/home

The minimum sized transaction during this period seems to be 0.29 kb. Meaning that the 1mb fork has processed at least 2.2 MB of transactions since the 2mb fork became stuck.

If they're coinbase transactions (or descend from them) they can't be used on the other side of the split so you have to take them out from your total calculations.

I'm testing mining/mempool stuff right now and will report back.

If they're coinbase transactions (or descend from them) they can't be used on the other side of the split so you have to take them out from your total calculations.

Thanks, makes sense! Bitcoin newb here.

Somebody with testnet5 coins should simply create 5k transactions:

for i in {0..9999}; do bitcoin-cli sendtoaddress $addr 0.001; done

Looks like we mined our 1MB block: http://btcfaucet.ix28uktqsp.us-west-2.elasticbeanstalk.com/blocks/000000005a91d978c9527d202fc98acaebaee4f177f0b5d732f741d4c99b7a2d

@jrallison Out of curiosity, did you mine this with the default codebase seen here?

https://github.com/btc1/bitcoin/blob/segwit2x/src/policy/policy.h#L17

Thank You.

@jrallison Out of curiosity, did you mine this with the default codebase seen here?

I'm just a concerned bitcoin newb/hodler... I didn't mine it, just noticed the 2mb fork making progress after I commented here.

@friendsofbitcoin That is just a policy setting, which will likely remain untouched for segwit2x release - thus defaulting to smaller blocks absent miner updating their configuration file.

To mine a larger block, miners should opt into that with a setting in bitcoin.conf:

blockmaxweight=8000000

Chain is now un-stuck. Closing issue.

{
  "hash": "000000005a91d978c9527d202fc98acaebaee4f177f0b5d732f741d4c99b7a2d",
  "confirmations": 2401,
  "strippedsize": 1051890,
  "size": 1051890,
  "weight": 4207560,
  "height": 27071,
  "version": 536870930,
  "versionHex": "20000012",
  "merkleroot": "a9eb2319ca2c5ea19cae277b67da72b71913ee78134caa5a2cd3d57e1879ef6f",
  "tx": [
   ...
  ],
  "time": 1499734447,
  "mediantime": 1499635609,
  "nonce": 3338783941,
  "bits": "1d00ffff",
  "difficulty": 1,
  "chainwork": "000000000000000000000000000000000000000000000000017ba3c89e843173",
  "previousblockhash": "0000000035a7b078c8b54e33b496dcbd66f8d52049da3684d80291d1cc13f29a",
  "nextblockhash": "000000001482a422d9eb9cab055b4ce4672577540aa85e0800902e5a0ad2fd89"
}

@friendsofbitcoin That is just a policy setting, which will likely remain untouched for segwit2x release - thus defaulting to smaller blocks absent miner updating their configuration file.

To mine a larger block, miners should opt into that with a setting in bitcoin.conf

Thanks for the clarification, @jgarzik !

That brings up one additional question though, can a miner set:

blockmaxweight=8000000

prior to the hard fork block, and still generate valid blocks at <= 4000000 block weight? Or will the mining code always attempt to build invalid 8000000 weight blocks prior to the hard fork block?

Newb bitcoin user, but a professional developer and briefly looking though the code it seems to use the provided blockmaxweight exclusively? But I'm a newb, so... probably wrong.

@jrallison Any blockmaxweight configuration setting which is too large for the consensus rules is clamped to the largest possible value permitted on the chain at that moment. It's ok to set a too-large value there.

@jgarzik Thanks for the clarification. Does this mean there might be a coordination problem due to certain miners using the default setting instead of updating the weight leading to the same problem we see today?

@friendsofbitcoin
Good question! It sounds like "too large values" are ok, as they're constrained by consensus rules in consensus.h. However, I'm not sure the same is true with values that are too small, is it?

Given: DEFAULT_BLOCK_MAX_SIZE = 750000, DEFAULT_BLOCK_MAX_WEIGHT = 3000000, and a SCALE FACTOR of 4, it would be impossible for a miner to mine a block larger than 1MB at the predetermined blockheight for the hardfork... wouldn't it? What .conf settings are necessary to ensure the miner works before, during, and after the hardfork without modifications?

@opetruzel Set blockmaxweight as above in bitcoin.conf.

@jgarzik
That's it? Ok, that's easy enough. Would that also work (or simply be completely ignored) prior to SegWit activation? If so, why not make that the default? It might be a good idea to have defaults that don't prevent miners from being able to mine the HF block.

Hi guys,

I don´t see that block in the testnet5 blockchain explorer. This 0.3Kb block shows under 27071:

https://testnet5.blockchain.info/block/0000000016b2af58fc30fef380a4cec7262858e68aaa0bad37a9c419257d0636

I am assuming correctly and testnet5 did not fork?

I don´t see that block in the testnet5 blockchain explorer. This 0.3Kb block shows under 27071:

testnet5.blockchain.info followed the 1MB (legacy) fork and progressed along throughout this issue for the 2MB fork (that domain is referenced above quite frequently as such).

I am assuming correctly and testnet5 did not fork?

👍

testnet5.blockchain.info is syncing the right chain now.

nice my doings showing some results lately.

i was directing money from outside into the testnet. you guys do not know that mainnets in reality are the testnet environment. its coded that way.

this is on purpose for safety reasons in relation to dumb developer guys.
it keeps peoples doings outside and only let guys having access to the real chain when time is ready to it.
took me a while to figure that out but now things are running.

next will be getting better synchronisation to ropsten testnet from ethereum.

to getting better interaction for mycelium2toshi and vice versa.

i could also need some guys helping me with the customization for the apps.

thx in advance ;)