blockchain.info is even worse than that actually - I've seen them display the coinbase in the middle of a block.

Feel free to look into the possible bug I found and make up a patch if I'm right - I'm happy to be scooped. That said, it's a rare enough issue that fixing it won't be something they'll rush; it should get at least a month or two of testing if not more.

Trusted execution/remote attestation is enormously useful.

Remember that Hal's reusable proof-of-work scheme created a tradable asset directly from remote attestation and an honest ledger keeper. Similarly MintChip is basically a trusted hardware scheme. In principle you don't even need the blockchain at all if you can trust the other party to record coins moved accurately, and in practice with a blockchain as a source of secure value you can use careful engineering to limit the losses due to any broken trusted hardware implementation and provide a way to move value from one incompatible system to another.

General purpose and reasonably secure trusted execution with remote attestation would be truly groundbreaking if it can be made widely available, and not just for Bitcoin or even just financial applications. As an example Tor nodes can use remote attestation to prove they are not keeping logs of what data passes through them. In conjunction with fixed rate, fixed time slot networking this gives much better anonymity guarantees than Tor can provide right now, and with remote attestation systems guaranteed by distinct vendors - say an implementation from a US company, from a Russian company, and from a Chinese company - you can force all parties to work together to break your anonymity.

There might be reasons other than engineering that have prevented secure remote attesting TPM's from being becoming available to the general consumer...


edit: FWIW the link says that the TPM's in consumer hardware don't support remote attestation (via the quoting mechanism) because none of the certificates are signed. That's actually incorrect: at least one of the major TPM vendors, Infineon, signs the keypairs for the standalone chips they sell. (surface mount SOIC20 package FWIW; you can buy them on digikey) The issue is actually that the hardware is not secure at all and can be attacked trivially given physical access. Now with tamper protection that's not an issue, but you can't (yet) buy tamper-proof hardware with those chips in them, let alone tamper-proof hardware with the keys signed by the manufacturer in a trust chain. (AFAIK the few TPM's that are integrated into the North Bridge in some Intel chipsets do not come with certificates for their keys)

Excellent points.

To simplify things you can basically say merge mining in general has this problem that because you are mining multiple chains, and thus have multiple sources of profit, the actual investment in mining any one chain is low so you're incentive to validate and do the job properly is less.

You're not looking at the transactions I am.

The end of the chain I'm talking about is a20d26236c45724677fe3f8de380450994342f3107301be67669d700c0fc2d22 which were all included in block 000000000000016779d88a16b6d71ebd53ddf860f466f1f3d906b43a45f50865; note how the last transaction in the chain has no fee, so it's not a child-pays-parent issue either. (well, possibly it's due to buggy child-pays-parent code, but the owner of BTC Guild has said they're running stock bitcoind)

Actually there are some subtle flaws possible with PoW schemes where you can't easily tell what any given leaf is for, especially if you want to define total difficulty such that subsequent miners add to it regardless of what chain they are mining: PoW reuse and PoW hiding. Basically you don't want it to be possible to use a PoW twice, and you also don't want to make it easy to hide the chain that was worked on and reveal it after the fact.

The latter problem essentially comes down to the fact that you don't want it to be possible for a lot of work to be done on a chain - adding blocks to it - without that being public knowledge. PoW schemes don't have that problem generally because they assume no on entity controls more than 50% of the hashing power. The chain can only be extended by being public so lots of people work on it.

But with a timestamping scheme the whole point is to let the chain be extended by people who aren't involved with your currency, and may not even know it exists. But lets jump to problem #1 again for a second.

If your timestamping scheme's merkle tree allows the block hash for the chain to be placed anywhere in the tree's roots someone can mine two blocks at once. This is bad because no node can know which of the two blocks is correct, and making one of the blocks preferred by a rule like "lowest block hash wins at a given height" causes convergence problems. (you can withhold a particularly good solution and release it after someone finds another block, making the best block tip your block again and resetting the confirmation)

The former problem has an (attempted) solution in the merged mining specification by having a system of slots for each alt-coin mined, and making the order of those slots deterministic. Unfortunately it's broken and doesn't work. FWIW this actually got implemented due to a slightly different and more serious problem: early attempts at merge mining still defined the block hash as the hash of the alt-chain's header, so you could mine multiple blocks in one go. A better merge mining system re: PoW re-use would be some kind of defined path, basically from the tip of the tree "go left, then right, then right, then left etc." in a long sequence, and provided the path follows the right sequence it's valid, but that's maybe a little lower level than the overall ideas I'm describing here.

Going back to problem #2, lets suppose chain height was defined as increasing for every "timestamp" block added to the overall chain. If #1 isn't solved, you can just mine the occasional block here and there, hold that back, and then suddenly tell the world "Hey! Look at this really long chain I have!", deceiving clients into thinking they're on a valid chain. It's not an insurmountable problem - carefully chosen rules to chose what the best block may be solve it - but it makes SPV clients quite a bit more complex and the whole issue needs to be very carefully considered. AFAIK no-one has done the research required to do this properly.

I know I haven't explained the issue fully, but that's kinda my point: even after seven paragraphs of text I'm not even close to talking about all the subtle issues and no-one is really sure if there are even more subtle problems inherent in these ideas. It'd be nice if some alt-coins explored them, but that's a lot more work than pump-n-dump schemes...

I think what's happening is the value is so large that it can reach the priority required for a free transaction in a single block, and due to a bug, that happens multiple times as the block is created.

CTransaction::AllowFree returns true if dPriority > COIN * 144 / 250, and dPriority is calculated as nValueIn * nConf / nTxSize.

So 500BTC * 1conf / 225bytes = 2.2 > 144 / 250 = 0.576; note how you could pull thus stunt with just 95.616BTC using the minimum possible (safe) transaction size of 166bytes.

The problem is how the number of confirmations is calculated: in CreateNewBlock() we have:


Now coins comes from view.GetCoins(txin.prevout.hash, coins). The thing is the coin view is updated as transactions are added to the block - see viewTemp.Flush(); later in the function - which means it looks like the transaction already has one confirmation even though that "confirmation" comes from the block being created right now!

The easiest solution would be to change The nConf calculation to remove the + 1:


...but that's gonna need testing.

I replied in the main forum: https://bitcointalk.org/index.php?topic=197169.0

When running a node becomes expensive enough that people can't do it for free you'll still be able to find full nodes willing to accept incoming connections. You'll pay for that service in a variety of ways:

1) Transaction fees: You connect directly to a miner who lets you do so because they want your transaction fees. They may require some # of transactions per unit time, and part of the agreement may be that you only send transactions to them. (easily verified) In return they'll run your bloom filter against incoming blocks, although don't be surprised if they force you to give them a bloom filter specific enough to identify exactly what addresses are in your wallet as part of the deal.

2) Pay-for-service: You pay for the service directly. In return they resend your transactions to miners to get them mined, possibly with preferential deals (kickbacks) that may or may not be public knowledge. They also run your bloom filter against the blockchain, and again, they may or may let you do so in a non-specific manner. Given AML regulations I wouldn't be surprised if the services that operate out in the open only allow you to tell them what addresses you are interested rather than a bloom filter obscuring that information. (AML rules apply to case #1 too)

3) Datamining: Google and other search engines already provide a lot of services purely in return for the data they can gather. The blockchain itself is a rich source of transaction data, made richer by figuring out the real identities behind the pseudonymous addresses on it. Just like #1 and #2 if you can determine who is sending what transactions and owns what addresses you can integrate that into a rich dataset to do things like get real-world information on what vendors are actually popular, which in turn can feed search engine results and other services.

It'll be interesting to see how AML regulations apply to all these services in the future. I suspect they'll eventually be subject to the same know-your-customer rules as any other financial service provider to help authorities link identities to Bitcoin addresses. This doesn't have to be very intrusive: in case #3 that might be as simple as using your Google login to authenticate with Google's Bitcoin servers.

Anonymous network technology is just barely good enough to support mining anonymously with 1MB blocks. (not hashing! I mean being a mining pool, solo-mining, or running p2pool) That isn't going to get better quickly, and could easily get worse if we see attacks on the Tor and I2P networks.

Considered this scenario:

1) Get Bitcoin address for payment from double-spend vulnerable merchant

2) Broadcast payment, and a double spend, at the same time

3) ~50% of nodes get your payment, %50 get your double-spend, each thinking the other is the double spend

4) If merchant's node gets payment transaction, run with the goods; 50:50 chance you'll have wound up paying for them.


Blockchain.info's shared-send mixer guards against this because they have a huge network of nodes watching the network and can detect double-spends; the solution for your average merchant is to either not accept zero-conf (highly recommended) or get double-spend propagation so nodes propagate the first double-spend they see as well as the initial transaction implemented in the Bitcoin reference client.

tl;dr: Making dust outputs non-standard is just one of a huge variety of ways to pull off a zero-conf double-spend.

I was talking about core technology - for that it is mostly an OR decision strongly based on decentralization. Heck, I would have followed it up with something similar to this pull request but John went of and did it first.


Probably one of the hardest things we may face is that even just working on those technologies and having your name linked to doing so isn't something one should take lightly - yet, building trust in software is difficult enough when the people involved are known publicly, and a key non-monetary reason people work on opensource software is recognition.

Beyond that, there are always foundations, but I can't think of a single one that has operated anonymously.

$7,000, the other $3,000 is going towards blow and hookers. (we're not filming that)

As for the team: http://www.youtube.com/watch?v=0Z09bNgSeMI <- I'm the handsome one.


Seriously, you think the tens of millions of Mt. Gox trade volume every day goes to buying socks?

Consider the user experience if a pure miner change is implemented:

You send a transaction. It reliably gets to the 10% of miners still implementing the rules you depend on, and it takes quite awhile to get mined. Annoying, but your transaction gets mined, and the person you sent it too sees it immediately.

On the other hand, with a relay-related rule, unless there happens to be a path from you to that miner of relay nodes willing to relay your transaction, absolutely nothing happens and you are left scratching your head wondering why.

Like it or not, changing relay rules is a much bigger change than chaning block inclusion rules, and it's much more effective at blocking transactions until a high number of nodes change their settings.


Sorry, but calling it a "network protocol rule" sounds pretty accurate to me. It's not a blockchain rule, it's not a block inclusion rule, it's something that decides if a transaction can propagate on the P2P network.

Having read jdillon's stuff, I'm pretty sympathetic to the idea that we should be accurate in what this is, blocking. Yeah, it leads to massive forum threads, but again, I agree with him that the fact we're seeing that just shows how little people understand where Bitcoin is going.

Don't spread misinformation.

You have to connect directly to miners to get those transactions in a block because 0.8.2 nodes will not relay transactions with dust outputs at all.

Essentially speaking the network protocol has been changed.

China has effectively muzzled the internet, and they've been extremely smart about doing it. Saying dissident things is not illegal in China, however organizing in groups to do so is.

China muzzles the internet by allowing some dissidence, but making doing so inconvenient at every step, and clamping down on groups as they pop up. Sadly it's a very effective approach.


Intermediaries can be anonymous, and even better than that, there are ways to use cryptography and incentives that let you trust anonymous intermediaries, just like Bitcoin let you trust an anonymous group of miners.


I wrote elsewhere how the smartest thing governments can do to stop Bitcoin is attack Bitcoin as a payment system by providing secure, zero-fee, no chargeback fraud alternatives. Even better is if these alternatives are mostly anonymous, or claim to be. I suspect the Canadian Mint is attempting to do exactly that with their MintChip project, although it's also quite possible it's just an attempt at ensuring the mint has a future in a cashless society.

What Bitcoin has to offer is deflation, decentralization and anonymity. If we screw up decentralization, Bitcoin will be no different from any other payment network.

Good to hear! Corrected


Don't think Tor is totally unblockable. The Chinese government has had a lot of success discouraging Tor and proxies in general, especially for the purpose of Bitcoin, by simply slowing down any encrypted traffic. Bitcoin is especially vulnerable to such techniques because miners need a lot of bandwidth to quickly get blocks when they are created, or their orphan rate will be too high to be profitable compared to miners who do have government support and have access to faster communications.

Nothing FUD about it at all.

The smartest thing governments can do to fight Bitcoin is create alternatives like mintchip that have low or no transaction fees, offer merchants chargeback fraud protection with irreversible payments, but are denominated in a currency consumers already have. Getting money in and out of those alternatives can be made much easier than Bitcoin ever will be, yet they can build in secret or not so secret forms of transaction tracking to control anonymity, or just leave the payment systems anonymous at first and crack down later.

Bitcoin has nothing special to offer as a payment platform other than freedom from regulation.

Send an email to Lindsay Holland <lindsay@bitcoinfoundation.org> explaining that you are no longer willing to be a Bitcoin Foundation member. She'll take you off the membership list and take your name off the public list of supporters. (if chose to have your name public when you signed up)

Do include your reasons for leaving the foundation in your email.

We discussed how to approach communicating the 1MB limit for quite awhile before we decided on the approach that we did. There isn't anyone reasonable in this discussion that thinks the limit is set in stone forever, however it will be years before it's safe to raise it, if ever. Network bandwidth is something limited not by technology, but by what regulatory environment you live in. It has everything to do with what your local telecom monopolies and governments think the internet should be used for than it does how many transistors can fit on a piece of silicon. Anonymous network bandwidth is especially fragile: look at how Japan's national police force has been talking about forcing ISPs to block Tor and proxies and even making using them illegal. EDIT: apparently this is incorrect The decision that it's safe to raise the 1MB limit won't be one made on technical grounds and it can't be made safely until we better understand how governments perceive Bitcoin.

With that in mind simplifying the message to talk about the 1MB limit directly, rather than talking about it as some wishy-washy "small blocks" message seemed like the right approach. By the time the limit can be raised safely many years will have passed, plenty of time for people to understand the nuances involved.


As for calling Bitcoin a democracy again I and the rest of my team decided it was quite reasonable to talk about it that way. The mining process is a strange type of vote, but in the grand scheme of things it's still a vote. For instance P2SH was implemented by miners voting that they would ban transactions that didn't follow the P2SH rules.

The Bitcoin blockchain rules are essentially our Constitution. They can be changed, but it takes a supermajority agreement to do so. 51% of miners need to agree to do so, and a reasonably large fraction of economic activity needs to follow.

You have to remember that a lot less than a majority of economic activity needs to follow because a blockchain without majority support from miners the blockchain is not secure. Specifically, note how with just over 2/3rds miner support the remaining 1/3rd of miners can be attacked by those supporting the new rules. That 1/3rd can't outvote the new blockchain, and at the same time they themselves can be outvoted, IE 51% attacked, making the blockchain with less miner support insecure and worthless regardless of what the economic majority wants.

FWIW I have heard from third-parties that Mt. Gox runs their trading engine on the slow, but exceptionally secure, hardware security modules used by banks for things like ATM machines.

Mt. Gox has the unique problem that they can't reverse transactions, which means their security and stability requirements for their trading engine are significantly higher than faced by conventional exchanges. Especially with high-speed trading engines it's common to cut a lot of corners with regard to security and stability because if the system does screw up the problem can be fixed after the fact. If Mt. Gox's system screws up and someone withdraws the Bitcoins they shouldn't have obtained Mt. Gox can do nothing to reverse that transaction.