Which one? Do you mean Finney attack (committed by the pool and buyer against some merchant)? Or do you mean block withholding attack committed by individual miner against mining pool?
If there is another kind of withholding attack I would be delighted to know.

You know what you are hashing, right?
Pool sends you work which includes coinbase address. If it sent some strange coinbase address (not official one belonging to Slush), you would notice. If it sent Slush's pool Coinbase and then Slush used another server to broadcast that block, reward would still go to Slush's pool and you would notice. I do not understand your problem.

Hallo.
Czech Ministry of Interior handles such cases. Some informations are in English, most of them are Czech only.
http://www.mvcr.cz/mvcren/article/citizenship-of-the-czech-republic.aspx
http://www.mvcr.cz/clanek/udeleni-statniho-obcanstvi-ceske-republiky.aspx
http://www.mvcr.cz/clanek/informace-k-novemu-zakonu-o-statnim-obcanstvi-cr.aspx

What I get from quick reading the text, I think you will need permanent residence ("permanent residence permit for the Czech Republic"). Being born in CR can be advantageous to the citizenship getting, but it is not automatic.

And it is up again.

I see no trading since 14:45.
https://bitcoinwisdom.com/markets/huobi/btccny

Have there been any trades on Huobi in the last 5 hours?

That is why dumps also occur at prices like 950$, 1050$, 1040$. 

Many people will dump around $1000. That is psychological resistance. See the dumps of 27/11 - 28/11 2013.

Replace concrete blocks by (expanded) polystyrene blocks. Or with inflatable toy blocks with handles.
Whether current content of Bitcoin-blocks is closer to concrete or to inflatable toys with (easy to carry) handles, that is matter of perspective.

Unless blocksize fighting isn't (in a part) actually their fight. 

OK, my mistake.

I hope Slush stays at 1MB limit. Otherwise it is time for me to move to the pool that does and respects non-hardforked rules. (Does not matter if it is called "Core" or otherwise.)
But of course people who prefer >1MB branch (and believe that it won't lose its utility and consequently value) are free to commit their hashpower to pool that creates bigblocks.
Problem is that pool operators have not stated their policy clearly (and they are more and more influenced by mass pressures). And even if they did, there is no guarantee they will keep this.

Nobody else have any ideas or opinions?
Is there a better section of forum for this thread?

Regular users can refuse (do not accept) forked bitcoins as payment. Or they can migrate to services which stay on consensus path.
Big mining pools are composed of many small miners (hashers). Big companies would not find their BTC as valuable if common people (and/or significant players) won't accept them as payment or as wage or as collateral or whatever.

Hallo,
I was thinking about a way to clarify current heated and politicized blocksize debate. Simple statements about different levels of support encoded in coinbase would be helpful and would allow predictable conditions for various agents in Bitcoin ecosystem.

Would something like this be possible today? There are of course lists about which pool support what branch (Bitcoin Classic, maxblocksize increase, Bitcoin Core, Roadmap, ...). But such lists are biased depending on the source, policies develop and statements from various representatives are fuzzy and sometimes contradictory.

We have several large pools, but despite this the mining is not centralized, because these pools are composed of large number of individual miners. Clear policy expressed in coinbase would be guide for these small miners where to (re)direct their mining power according to their opinions.

---

Base of my proposal (which is open to comments and suggestions) is this:
- four levels of support (active/passive/opposed) (+//-)
- Main branches as simple strings (Core, Classic, Unlimited, Roadmap, 1MB, 2MB, 4MB, 2-4-6, BIP10x).
- Strings signed by some simplified way, if possible

For example:
- String: "*Core+,Roadmap+,Classic,4MB-*" means:

• Active support for Core and Roadmap (Our poll will generate blocks according to Core&Roadmap specification)
• Passive support for Classic (We will not generate blocks according to Classic specification. However, we will build on them.)
• Opposition to 4MB (We will never generate 4MB blocks and we will actively orphan such blocks - that is consider them invalid and inconsequential. No matter where this proposal comes from (included in Core, included in Classic) and which Developers support it.)

- String: "*Core,Roadmap(RBF)-,Classic+,4MB*" means:

• Passive support for Core (We will consider <1MB blocks as valid)
• Opposition to RBF (We will orphan/ignore blocks containing any RBF transactions as specified by Roadmap)
• Active support for Classic (We will happily and preferentially generate 2MB blocks according to Classic specification. We will build on them.)
• Passive support for 4MB (We will not generate 4MB blocks, but we will not ignore such blocks - We will reluctantly bulid on them.)

Of course strings can be more detailed (*SegWitCore-,SegWitClassic+,>1MB+,>8MB(until2018)-*). Interpretation would be matter of external actors (I think someone would probably create webpage for this.] But all interpretations would allow fallback to verifiable data for everyone.


As to the signing... I placed strings between two * symbols for a reason. I think this is the way they should be in coinbase followed by some simple signature. Reason for this: Any pool can pose as another pool (eg. BitFury can put "Slush" string in coinbase, Slush can put "Eligius" there etc.) and by this way fake statement of someone else. Simple privkey/pubkey pair where privkey signs *string* between ** and pubkey published on pools webpage/stated by trustworthy source/pool operator can solve this. Statements can also be signed by Bitcoin address publicly stated by pool in advance. But the signature should be short enough?! I do not have specific idea how to do this.

It would be nice if every pool would state several different (even contradictory) policies and open different addresses/ports for its hashers to "vote" on them a dynamically change their votes. Data analysis people would love this! But of course pool operators can express their policies by limiting the choice or not signalizing at all.

So...what do you think?

So Eligius will likely mine on original chain and consider all >1MB blocks invalid even under pressure of majority mining power, economic actors, popular "vote" and government?

Is there any reliable information about which exchanges WILL NOT support the fork? I have already tried to start a list here, but no contributions yet...

Did Slush state his policy towards 2MB (or any other) hardfork*? I know he allowed choice between XT and non-XT in the past. Will this be the case again? So will there be a possibility to commit my hashpower to the branch that will never ever accept >1MB block as valid?(And likewise to commit it by using different address/port to the hardforked branch that will accept it.)
Or will Slush prefer only one branch?


* - This currently means Bicoin Classic, but the name can change in the future as push for bigger blocks divergent from Core Roadmap will surely be communicated under various names again in the future.

It depends on SegWit program. I think it will be p... for P2WPKH address and 7... for a P2WSH address.
But it looks that BIPs change on the go.

So waiting for at least one confirmation (if all miner upgrade) and 2-3 confirmations if majority upgrade. OR Upgrading wallet.
Exactly those two solutions I excluded and did not ask for.