[Maybe we can include this patch into 0.9 already.]

If a hard-fork is allowed,In bitcoind 0.9, could we forbid discourage one address to mine more than N (maybe = 6) blocks in a row? In other words, the new bitcoin clients will give lower weight to (N + 1)th block mined by address A if the previous N blocks mined by A.

Normally we calculate chain length by sum(difficulty), but if a block is a 6th block mined by the same address in a row, we give it a 0.5 weight, then 0.25 for 7th, 0.125 for 8th... In this case, a long chain mined by the same address always has less sum(diff) than a normal 6 chain.

This certainly will not prevent general 51% attacking since the attacker can change the mining address easily, but considering currently most mining pools are using one mining address, it will be useful to avoid panic caused by big mining pools. As long as the big mining pool promise to use one address (easily verifiable and maybe can be guaranteed (see 3)), we no longer need to worry about them any more.

Any thoughts about that?

EDIT: Maybe we can include this patch into 0.9 already. Suppose we include this in 0.9, what will happen?
1) Will pools will be affected? I've checked the history, it is very rare for a pool to mine more than 6 blocks in a row now, therefore pools don't need to worry that they have to give up mining a block frequently.
2) Will hard fork caused by this patch? As long as all the big pools installed the new version, it is almost impossible for small miners to mine 6 blocks in a row. Therefore, as long as Gavin has the consensus from the main pool operators, it's safe to include in 0.9 without causing problem.
    Changed from 'reject' to 'discourage', and no need to worry about hard fork any more.

3) For Stratum and GBT protocol, a new pool miner software can be released so that a pool has a pre-configured mining address and the miner will reject any task having a different coinbase output address.

EDIT:
One main drawback is this cannot prevent multiple pools (probably run by the same person) work together to double spend. Nonetheless, it's still better than now.


EDIT: added an example to show why my proposal helps preventing pool from double spending
Here's an example:

Suppose a big pool P has 51% of network hashing rate, and decides to double spend. He spend a large number of BTC in block 300000, and then his pool secretly quit the main chain and mining his own 300000'. He mined 300000', 300001', ..., but keep it secret without publishing. Once the main chain arrives 300005, his spending has got 6 confirmation already and he get whatever he bought, he announces his private chain (at that time, it's longer than 6 due to his higher hashing rate than others). Only at this time, people will notice the double spending, but according to the rule of bitcoin protocol, the longer chain always wins, so 300000' - 300006' wins. There will be a reorganization, and the block 300000 to 300005 are orphaned. No one can fix this without causing hard forks.

If my proposal is approved, this pool cannot double spend without changing his mining address. Otherwise, his 7-chain (or even 8-chain, 10-chain, 100-chain) has less sum(diff) than the main 6-chain so it cannot replace the main chain at all. Therefore, the pool has to change the mining address when he secretly mines a long private chain, and that will give us the alert. Moreover, if miners choose to reject changing the mining address for a pool, this kind of double spending will never work.

Hi, I've created a website to facilitate people to check their counterpart (XCP) balance.
http://www.counterparty-explorer.com/

Note:
1) Valid burn:
   a) all input addresses should be identical
   b) the FIRST output HAS TO BE the burn address.
   c) only BTC burnt up to 1 BTC limit is considered valid.
This complies with the official couterpartd.

2) Not polished yet, so it's only plain text for now. Please use Ctrl-F to search your address. Per-address detail will be added later.

Disclaimer: this is not an official site, so the balance may be different with the couterpartd.

Any feedback is welcome.

One of the main reasons why people love BTC is  that they think BTC is democratic and nobody can damage it since it is protected by millions of users. Call me stupid if you want cause I feel quite unconformable now when I realized just 3 to 5 persons (the operators of BTCGuild, GHash, Eligius, BitMinter, and Slush. See https://blockchain.info/pools) can effectively damage the who ecosystem.

One example is the current proposal of Luke Jr (see https://bitcointalk.org/index.php?topic=334316.0). Yes, this time that patch may be not so harmful and you happen to side with Luke. But eventually you may disagree on other more serious issues but you have to put all your trust on that 3 to 5 operators.

Could we do something in the protocol, so that no mining pool could exceeds 5% of the market share and bring back BTC to be real decentralized again?

Could you provide a concrete example to explain why reusing addresses by A will affect B if B always carefully choosing address. and how both A and B never reusing addresses prevent it? I'm still not so clear about it.

A always reuses addresses. Blockchain.info uses this to display their name and IP address along with their transactions, everyone else they've ever transacted with knows who they are, anyone can identify who they are with a simple google search, etc. Because A reuses so often even if A sometimes doesn't reuse, the coins they receive inevitably get mixed up with the non-reused one. A is entirely public.

Now B is super careful and paranoid... and we're not even in a world where blacklisting or whitelisting prevents B from comfortably using his paranoid practices. He never reuses.  Someone is trying to figure out who B is because they want to defraud him.  Initially they are thwarted by B's pratices but then they see that B initially received his coins from A. Everyone knows who A is. Moreover, they see when they did so. From that alone they've learned a ton of information about B, beyond that they can now go ask A to tell them— they could coerce A, or just trick him, as we've already established that A is pretty happy go lucky and not very cautious.   Beyond that it isn't just A,  B also transacts with other people who are not hygienic and those all potentially leak information too.

This actually works in practice, too... A nice whitehat hacker on IRC was playing around with brainwallet cracking and hit a phrase with ~250 BTC in it.  We were able to identify the owner from just the address alone, because they'd been paid by a Bitcoin service that reused addresses and he was able to talk them into giving up the users contact information. He actually got the user on the phone, they were shocked and confused— but grateful to not be out their coin.  A happy ending there. (This isn't the only example of it, by far ... but its one of the more fun ones).

Uh. We've gone pretty far offtopic here, perhaps these posts should be split from this thread?

Actually I lost here:

Initially they are thwarted by B's pratices but then they see that B initially received his coins from A.

How can they know that transaction belongs to B?

A proposal to help US investors of BtcQuick:

As we know, this stock, unlike most others, has sound foundation and solid dividend. If not for the BF issue, the share price will be well above 0.0003. US investors, however, have to sell this stock at current market price, which is pretty unfair if they believe the price will rise after everything calms down. They could at least lose much less if they could stay in the market for two to three months.

So how about instead of selling shares at current market price, US investors (or other investors don't want to submit documents) sell a contract to verified investors. By selling the contract, he could benefit a higher return if the share price recovers in certain period.

The contract includes the following elements (amount, current price, target price, expire date, commission). Then
1) The buyer sends BTC (amount * target price - commission) to an escrow service.
2) The seller transfers the shares to the buyer.
3) Once buyer receives the shares, she/he releases (amount * current price) in the escrow to the seller.
4) If the market price exceeds (strictly larger than) the target price any time before the expire date, the rest in escrow will be released to the seller.
5) Otherwise, the rest in the escrow will be returned back to the buyer on the expire date.

This proposal has various advantage.
1) It's like an option escrowed out of the stock market, so once the contract is sold, the seller can safely leave the BF.
2) The seller does not need to trust the buyer, vice versa.
3) This is a one-time contract without future trading so it is much easier than a private proxy service, which is too complex for an escrow service.
4) Since this is a one-to-one one-time contract, there should be much less legal issues compared with a proxy service.

Any thoughts? If you are US investors (or other investors don't want to stay in BF), are you interested in this contract?

For example, personally I can accept buying a contract as (60000, 0.0001, 0.00025, Jan 10 2014, 0.9BTC) if I pass the verification of Weexchange.  Target price can be any value between 0.0002 to 0.0004 as long as the commission = 10% * amount * (target price - current price).

If you look at the trade history of labcoin in btct.co today, you may also notice this pattern.
There're many small buys with 1 or 2 shares (considering the price is < 0.002, that's really weird) to push up the prices and then a large sell (> 1000shares). I'm not an expert of stock market. Anyone with more experience can help to explain this? Thanks a lot. Appreciated a lot if you help to quote in the labcoin thread in "securities" board.