http://www.bloomberg.com/news/2014-02-10/bitcoin-exchange-mt-gox-says-users-can-withdraw-cash-as-normal.html

Bitcoin Exchange Mt. Gox Says Users Can Withdraw Cash as Normal

 believe it?

2) Bitcoin Foundation could setup some public servers that always run the latest official version of the bitcoin client. Exchanges should then be able to verify that the transaction is legitimate to the latest bitcoin client before broadcasting them.

No, it won't work. Miners will simply create an extra output in the reward transaction, sending 0 bitcoin to OP_TRUE. They will then use it as an input for another OP_TRUE output, and repeat this process. Since the process is totally deterministic, miners won't need to broadcast these dummy transactions. Other miners will recreate the full block locally. So we go back to the current system: with less (real) transactions, the orphan rate is lower.

EDIT: The workaround suggest above does not work due to the 100-block maturity rule. A trivial fix is to put the dummy transaction as the second transaction in a block, and the rest are derived in the deterministic way.

What if we required a minimum number of transactions

What's wrong with the minimum block size idea?  If dummy data doesn't work then make it require real transactions.

Miners will only fill blocks with dummy transactions if they don't have enough available transactions in their mempool.  Otherwise they'll fill it with transactions that earn them fees.  If we can expect a certain transaction rate on the bitcoin network then the min block size could be set accordingly and so we shouldn't see much use of dummy transactions.

Disadvantaged how? If later blocks take precedence over earlier blocks, because they have more bitcoin-days-destroyed, it makes it easier for someone who controls lots of bitcoin-days (like the FBI) to mount an attack.

Hi,

I'm trying to create a multisig address from 3 addresses:

* mj1zkN24ADDKPD8yCCXvBYtpJHz8FqJ7DC (pubkey: 028c82c09e3b893f1611cef20c86b399f27d9d76fe9c456df33a0f8319958689f7)
* mhqQ5ZLETv3y3wgXYcLPY9W7ssziscFKsh (pubkey: 0246137887433809d28ba48d08153f5461ced55703f27fd46dedb775a5f5fe8a86)
* muLBgX7Y9D3zQGeoXjWZ3dPowACxbTN8nd (pubkey: 0352cf6e2c4d36294a89fe520ec6f4fa29859e6f69b549b8eb4128b55f596923c6)

I used createmultisig 2 '["addr1","addr2","addr3"]' which gives me: 2MyMdJW7GpkULivugRMNqrVuaoqFenc7ioS

When I tryed to send 3 btc to the address: 2MyMdJW7GpkULivugRMNqrVuaoqFenc7ioS

This is the transaction: http://testnet.btclook.com/txn/e4a750d7c2547352ced95bf1095d8c8e805bc640fce93e27061d0c201ebae2ac

The address looks like "? ? ?", why?

The address shows nothing: http://testnet.btclook.com/addr/2MyMdJW7GpkULivugRMNqrVuaoqFenc7ioS

What am I doing wrong?

It actually raises a really interesting theoretical cryptography question: Is it possible to create a long string (the padding bytes) such that you can prove it was not possible to derive the string from a smaller secondary string? (AKA a trapdoor)

You can probably come up with a scheme where the second string was some kind of secret, such that knowledge of it could be exploited, perhaps to steal the value of some fidelity bond. For instance you could computer the padding bytes as H(secret || i) with i in (0, n) and secret being some ECC privkey for a valuable txout; giving the privkey to other miners is obviously risky.

The problem is if anything I think that actually encourages centralization: I can safely give a small number of other mining pools that privkey if we have a legal agreement to only use it for the intended purpose. If my funds go missing, I have a pretty good idea who did it and can get the lawyers involved. The smaller the number of pools, the more powerful and enforcable this mechanisms is; with two pools I have 100% certainty who defrauded me. Unfortunately that's the exact opposite of what the padding idea is trying to accomplish...

I was inclined to think the Russia scare was FUD.  Watching BTC-e now I'm not so sure.  A lot of pressure there.

Monitoring the situation of handling the so-called virtual currencies (kriptovalyut) shows a growing interest to them, including the purpose of legalization (laundering) of proceeds from crime.
In this regard, the General Prosecutor of the Russian Federation, chaired by Chief of the supervision of the execution of federal law Anatoly Palamarchuk expert group meeting held at the Interagency Working Group on combating crimes in the sphere of the economy devoted to the use of the territory of the Russian anonymous payment systems and kriptovalyut.
The work of this group was attended by Deputy Chairman of the Central Bank of Russia Dmitry Skobelkin, heads of relevant departments of the Bank of Russia, as well as officials of the Russian FSB and the Russian Interior Ministry, central staff of the General Prosecutor of Russia.
In accordance with Art. 27 of the Federal Law "On the Central Bank of the Russian Federation", "the official currency (currency) of the Russian Federation is the ruble. Introduction on the territory of Russia and other monetary units issue money substitutes is prohibited. " Certain distribution received anonymous payment systems and kriptovalyuty, including the most famous of them - Bitcoin are money substitutes and can not be used by individuals and legal entities.
Moreover, the distinguishing feature Bitcoin as a virtual mutual funds for accumulation and lack of security is a real value. Its price is determined solely by speculative actions that entails a high risk of loss of value and as a consequence, the violation of the right to keep its citizens and organizations.
Please keep in mind that the owners kriptovalyut today denied in Russia and other states ability to protect its interests in court or administrative order.
Following the meeting, outlining specific joint actions of the Bank of Russia and law enforcement to prevent possible violations in the sphere of money circulation in Russia, a number of specific solutions aimed at preventing violations of property rights of citizens and organizations associated with the use kriptovalyut. Taking into account international experience identified further areas of work on the legal regulation of this sector.
Development of the situation and the implementation of the above activities will be discussed at the next meeting of the expert group.

I know for that but any offical lpage/link?

Where do you see that? Thanks

It sounds like you are suggesting that miners will collude with each other to fix each other's invalid blocks. If that didn't happen, that any compression that a miner did to get his block under the minimum size would just result in his block being rejected.

Here's one potential argument against that: individuals running full nodes who just want everyone to play by the rules have no incentive to help miners cheat, so when their Bitcoin-QT software sees a small block get broadcast, then even if it is technically possible for them to 'fix' the block to make it larger, they don't want to, so they continue to wait for a larger block. Any cheating miners who start working off of the too-small block won't get any blocks they find accepted by users, because the cheating miners are building on a too-small block. So some corrupt miners can create their own fork of the blockchain if they want, which doesn't respect the min-blocksize protocol change, but no one will care because users will be using the chain that adheres to the protocol.

And here's a counter-argument suggesting that you and Cryddit are right: a group of cheating miners could do two things when they find a block: first, immediately broadcast the small/cheating version of the block. Then immediately broadcast the larger version of the block. Any miners who receive a cheating block will know that a valid block is probably going to follow very soon, so they fix the cheating block to make it valid, and start working off of it (otherwise they'd be worse off than other miners who did this). When they finally get the valid block, they think "yeah, I knew this block was going to come, I'm already working on it." When users of Bitcoin-QT get the cheating block, they will reject it, but they'll soon get the corresponding large block and accept it.

Did I miss anything?

Have the core developers thought much about if there is some clever trick to make it not work to broadcast an initial cheating block and then later broadcast a valid block?

The point is that any block with size less than the minimum size would be disallowed by the protocol. So it wouldn't matter if all the other nodes knew what the junk values would be.

This is exactly what I was about to post. It seems like an elegant solution with good incentives (if someone includes a reasonable fee with their transaction, the miner would rather have it in their block than some junk).

I haven't thought that deeply about this, but it may not be necessary to have the minimum block size be equal to the maximum block size. Could the minimum size of the next block be calculated by every node based on some property of the N previous blocks? The intuition is that we'd want the minimum size to be maybe 10% larger than the block size that we predict we'll need to include all transactions that pay a reasonable fee. So perhaps if this code were working right now, the min block size would be 250KB instead of 1MB, but the max block size would still be 1 MB.

no. HD addresses this question, but it does not solve the key sharing problem. keys, identities and transactions can appear in many different varieties as outlined above. my scheme above is in a larger context: how you share keys, how you create virtual/legal identities in the first place and what you would want to do with this kind of underlying system.

this is the opposite of stealth. its providing information to the public at the choosing of a person or group, either because that group wants that, or because it is forced to by a general public (like people force corporations/non-profits/governments to act in certain ways by market forces or elections). a simple example is somebody working on an opensource project, taking time based donations. instead of asking for as much as money he wants, he asks for a provable limited amount. this can be coupled with an assurance contract (kickstarter).

this pattern applies to a very wide variety of transaction types, non-profit orgs and government like entities, but also various for profit economic vehicles. the topology of transaction types is largely unexplored, because most are focused on a very narrow set of types (pure p2p / e-shopping).

5870 BTC bought.

Biggest recorded buy yet (unless they've made a typo, they've made one before).