To say there is a rough consensus that the 1MB block limit will be raised at some unspecified time in the future is missing the point. The real issue is, is there a consensus that a large fraction of the transaction volume will in the future happen off-chain? Given the range of opinions between you and Mike, who expect transaction fees to stay low enough for all but microtransactions, Pieter Wuille, who if I am correct is unsure, and Jeff Garzik, and Gregory Maxwell, who are both working on designs for off-chain transaction systems, I just don't see a consensus.

After all, for the user, the limit itself isn't the issue, the issue is how they will be expected to store and spend their Bitcoins, and what kind of security Bitcoin will provide them. I haven't seen anything from you or Mike actually talking concretely about what kind of protection from authorities and others trying to control Bitcoin that you expect Bitcoin to be able to provide. For instance, in the future, do you expect that by paying a sufficiently high fee can I expect get my transaction confirmed eventually, regardless of who I am or what the transaction is for? Do you expect me to be able to vote on what transactions do get confirmed and included in blocks, in proportion to the hashing power I possess? Do you expect me to be above to participate in Bitcoin by creating transactions and mining as a full validating node anonymously?



You know, I didn't think anything at first of the Wiki page on scaling advocating simply increasing the block size as required, even to the point of requiring full nodes to have tens of thousands of dollars worth of high speed internet connections and UTXO storage hardware. But eventually I started thinking about the implications - the turning point for me was really when I realized how large miners could use large blocks as a way to force smaller miners out of business.

Satoshi didn't foresee pool mining, the dangers of bloating the UTXO set, or even that multiple clients would be used. Bitcoin was a brilliant idea, don't get me wrong, but Satoshi was a person, not some all knowing all seeing deity. It doesn't surprise me the slightest that he might not have thought through all the implications of allowing the block size to increase without bound, just like he left Bitcoin with a scripting system that turns out to not have that many actual applications.

The massive forum dramas ultimately come down to the fact that regardless of whether the block size is left as it is, or increased, Bitcoin as we know it will change; there just isn't consensus on how it will change. You come from Google, a place of massive centralized server farms controlled by one company. Google's services work pretty well - centralization can have benefits - but many of us feel that goes down a very dangerous path. It's easy to see how a world where blocks are sufficiently large that only well funded pools with highly visible high-speed internet connections can lead to government and large businesses controlling Bitcoin. Fundamentally, distributing large amounts of data in a censorship resistant way is far harder than distributing small amounts of data.

The 250KB "limit" is simply the default maximum block size created by the reference implementation that most miners use. Nodes will still accept up to the hard maximum block size, which is 1MB.

For instance, on testnet there have been two 1MB blocks created: 00000000476781c04b82b3ea91af1a86f3a863e1c9312b50302ffa01b7bdf960 and 0000000010bf4453b170a6756d911e207734ae181af6c8c02b42787d5885b333

No, the coinbase transactions will always sum to more Bitcoins actually in circulation because of fees. After all, a coinbase is allowed to have up to subsidy + total fees in it's output, the subsidy part sums to the total Bitcoins in circulation, and the total fees can be as high as you want in a valid block. Thus the way to pull of the fraud is with the coinbase transaction, because proving the fraud (currently) requires every transaction in the block, and every input to every transaction in that block.

That "moonshot" is because someone created a single transaction with 94BTC in fees: 13dffdaef097881acfe9bdb5e6338192242d80161ffec264ee61cf23bc9a1164

Fees are rising, but they haven't spiked like you think they have.

Ask your self, can Mt. Gox prevent you from doing a face to face bitcoin exchange?

No.

As long as mining stays decentralized, your ability to perform a Bitcoin transaction will be exactly the same as anyone else's ability: pay the fee, and you're transaction gets confirmed. It doesn't matter if you're a huge bank settling accounts cross-borders, or just some guy who needs to wire money to your parents in Iran. You're all on a level playing ground because as long as no one entity controls more than 51% of the total hashing power, no-one can risk rejecting a valid block.

Over Bitcoin's relatively short period, the graph of the hashing speed of the network looks like this:



...and you want to link block size to that wild roller coaster, when we haven't even seen that ASICS will do?

Even on a log scale the hashing power has been wild, and it still could be if anyone finds a partial shortcut in SHA256:



That said, since a shortcut is rather unlikely, and probably would break SHA256 entirely anyway, not to mention cause a 51% attack, I could consider supporting a max block size calculated as something like 1MB*log10(hashs/second * k) But really, I'm mostly saying that because log10 of anything doesn't grow very fast...

This.

I'd consider myself a pretty knowledgeable guy about Bitcoin - I've even gotten a few lines of code into the reference client and once found a (minor) bug in code written by Satoshi dating back to almost the very first version.

You wanna know where I keep my coins for day-to-day spending? Easywallet. So it's centralized - so what? If it goes under I'm not going to cry about the $100 I have there, and I do care about how it ensures that every transaction I make it unlinkable, and since I access it over Tor, even Easywallet has a hard time figuring out who I am.

My savings though? Absolutely they're on the blockchain, with rock-solid security that I can trust - I've read most of the source-code myself. Sure, transactions won't be free, or even cheap, but you get what you pay for, and I know I'm getting the hashing security I paid for.

With cryptography we can create ways to audit services like Easywallet and make it impossible for them lie about how many coins back the balances in the ledgers they maintain. Eventually we can even create ways to shutdown those services instantly if they commit fraud. In fact, with some changes to the Bitcoin scripting, I think we can even make it possible for users of those services to automatically get refunds when fraud is proven, although I and others are still working on that idea - don't quote me on that yet.

The point is, we have options, and those options don't have to destroy the truly decentralized and censorship-proof blockchain we have now, just so people can make cheap bets on some silly gambling site.

This.

I'm running a timestamping service that's been making about two or three transactions an hour for the past few days, each with 0.0005BTC fees. Looks like about 90% to 95% of my transactions are confirming in the next block, and the rest within another block.

Seriously, if you can't spend a 0.001BTC - a bit less than 5 cents - to publish a transaction that thousands of computers have to verify and store for eternity in the one rock-solid high value decentralized currency known to man, stop complaining. I'm surprised the large-blocks/low-fees group hasn't been compared to the usual socialists wanting to centralize profit and decentralized costs yet... or maybe they have - following the forums with this crap is a full-time job.

You know, my timestamping thing, OpenTimestamps if you want to know,(1) has been called blockchain spam by some. For the technically inclined, no it doesn't bloat the UTXO space, but it does add blockchain space. However, it and other abuses like storing files in the blockchain will naturally be crowded out as transactions become more expensive, so the total damage will always be limited without centralized enforcement efforts like Mike's pleadings for miner's to "stop the satoshidice spam". Already TX fees would cost me $100USD/month to run the timestamper if every block had a timestamp transaction in it, so I'll soon have plenty of reasons to change the way it works, just like the price of gas gives people incentives not to waste it.

On the other hand, if we go ahead and let the maximum block size get as large as miners want, there's no reason not to use it for all sorts of BS things, and little we can do to stop abuse without centralization. Sadly, I suspect as it becomes more and more expensive to participate as a full-fledged miner, instead we'll just see the number of pools decrease, and P2Pool die off from lack of miners, until central efforts to "stop spam transactiosn" start happening, and then you're one step away from "stop silk road" being possible.

1) FWIW, it's not quite ready to be called production yet, but if you can find the software on github, go ahead and try it out.

Actually, rather than a testnet, I'm working on doing a Bitcoin network simulator, that works out how fast blocks and transactions propagate, as well as allowing for models of miner behavior.

Thanks! It's been useful, sent you 0.1BTC, the real kind.

I'd suggest website operators take a third approach: support Google Authenticator, or to be exact, RFC 6238 time-based one-time passwords. Basically under the hood it uses a secret key, which is cryptographically hashed with the current time, and that creates a secondary password. For your users they just install the Google Authenticator app on their smart phone, use the camera to scan a special QR code containing the secret key, and from then on after enter the 6 digit one time password every time they login in addition to their normal password. Blockchain.info and many other Bitcoin sites already use it, not to mention non-Bitcoin sites. You do need a smartphone, but they're pretty common these days. Unless hackers get your users password and their phone, they can't do anything.

Unlike Mike's suggestion of using Google sign-in, RFC 6238 doesn't send any information what-so-ever to third parties. Not when you login, or even that you are using Google Authenticator at all. For non-Bitcoin sites, I can see why Google sign-in could make a lot of sense - if you use Google analytics Google already knows when your users sign in anyway - but Bitcoin is a target and you really don't want to be one court-order away from suddenly finding that none of your customers can login. Google has a better track record than most of fighting court orders, but because they're infrastructure and employees are spread out across the world in most countries they have no choice but to follow court orders. For instance Google has an office in Argentina, and I could easily see a court order to force Google to block sign-ins to Bitcoin exchanges pushed through under the guise of enforcing that countries capital controls. Equally I can easily imagine Google getting a court order by the Argentinian government forcing them to reveal all the Google sign-in's made in that country in an attempt to identify and prosecute people violating those same capital controls. Your website wouldn't even have to be based in Argentina for any of this to happen.

Mike has a point about Google sign-in being "one strong basket", but court orders can do things no attacker ever could, and if your risk is court orders, centralization is the last thing you need.

...which means large miners can offer "direct-submission" contracts where they accept transactions with above average fees, then refund the fees after they get them mined, minus the orphan rate and some small cut of profit. It'd be a great way for satoshidice to operate for example, and you could submit the same transaction with multiple miners at once if the miners agree to sign their coinbases. (you'll have to audit that the orphans are real, but to do so the miner just has to keep track of every block they produce, orphaned or not)

How does this prevent a miner from creating their own transactions to game the coefficients? The only cost is the orphan rate, which can be kept well under 1% for a miner with sufficient infrastructure.

Regarding the maximum transaction rate, I worked it out using the most efficient possible transaction type and wrote up the results on the wiki.

Basically, 10.7tx/s is possible, although the actual rate will be somewhere between that and 5.2tx/s depending on how efficiently change can used managed.

I already mentioned this to you on IRC, but I'll repeat it again: tapping high-speed memory busses is a lot easier than you would think if they go off-chip. You can always first force the memory bus to run slower than it should with the over/underclocking settings, and then secondly build some custom hardware directly on the bus itself with a cheap microscope and a steady hand to sample the signal. After all, it's crypto, provided you don't actually crash the computer, you can try over and over again until you finally hit the key.

L1/L2 cache though... much, much much harder, especially on 22nm where probing busses even for the people at Intel becomes exceptionally difficult due to capacitance. The stuff we talked about on IRC re: L2 cache locking looks like it could really work.


Actually you can. Just make every chaum-token related thing update a counter of all the outstanding chaum tokens, with fraud being any mis-update of that counter. The audit log gets signed and so on, and published publicly. The tokens themselves are still perfectly private - it's just a counter.

Anyway I explained in more detail about my further fidelity-bonded ledgers idea on the bitcoin-dev email list: http://sourceforge.net/mailarchive/message.php?msg_id=30531383


I considered doing that, but I think the security in depth of chaum + trusted hardware is safer. You don't want to give attackers an incentive to break the hardware to break the security in addition to steal money; your most formidable opponents are likely to not care about theft.


If block-space is cheap, what make you think the UTXO set isn't going to just keep growing, and at a high rate? It's also the most expensive storage because it needs to support a lot of IOPs, yet all validating nodes must have a full copy.

Also, "5 different organizations", so basically you just need to take out five targets to do a heck of a lot of damage to Bitcoin... lovely.

This is what I don't get about you, on the one hand you're saying fidelity-bonded banks have a serious problem due to legality, they're banks basically, yet on the other hand you're happy to see a system so centralized that you expect just half a dozen entities in the world are able to maintain full historical chain data required to validate the blockchain in a truly trust-free manner. What exactly do you expect to happen when countries decide "OK, Bitcoin is illegal now."? Do you have any plans other than, "OK, you win"?


Well I mentioned banks because it's the simplest version of the idea that I could explain on the non-technical forum and that can be done with Bitcoin without any core technical changes to the protocol. If you're interested, I also wrote up a non-banking version, fidelity-bonded ledgers, which can be setup such that you are only relying on the third-party to keep an accurate ledger of transactions - they can't steal funds at all. That version requires a soft-fork though to enforce the validation rules, so implementing it is less certain.



For a given bank, yes, based on how much investment they made in hardware. A few hundred to a few thousand dollars worth of hardware could process thousands of transactions a second though; the requirement for audit logs verifiable by others is likely the real issue. A really high volume bank will actually operate, at the technical level, multiple "sub-banks" to split the load up, all of which can be made transparent to the user. (similar to how you care that you pay bitpay, not that you pay a particular address they gave you)



Thank you! I also need to give credit to Gregory Maxwell: while I came up with these ideas, they've been refined through discussions with him mainly, in particular it was his suggestion to combine the fidelity bonds with trusted hardware, and he realized they provide orthogonal protections from fraud.

Sane "colored coin" or "smartcoin" protocols don't depend on some fixed "1 satoshi = 1 share" ratio. Rather for each transaction moving an asset around they calculate what fraction of the asset was assigned to what transaction output, which means you can divide the asset indefinitely without requiring the actual amount of Bitcoins to change. If the asset represented by a txout is worth less than the minimum transaction fee, it's still dust that doesn't make sense to spend.

It's unfortunate that the first smartcoin-type protocols weren't written that way; on the other hand none of them have actually been used in practice. I've written a protocol that does this correctly as apart of my fidelity bonds protocol, see here although I haven't written code to implement it yet.

Speaking of, you made a "dust-spam non-standard" patch right? Where is it?

Technically speaking, that's a very clever idea.

Socially speaking though, it'll be an utter failure. Miners using pool have absolutely no incentive at all to verify the blocks they produce other than some vague desire to protect Bitcoin. This is why currently pools other than P2Pool aren't verified at all - Eligius supports getblocktemplate, but mining software that uses a full validating node to verify the blocks is hardware ever used.

Pools just aren't going to buy a bunch of expensive trusted computing hardware and switch their operations to use fragile trusted computing software just to please the 1% of miners who seem to care about this issue.

Those numbers are bogus and show very little understanding on the part of solex.

The problem is apparent if you look at transaction 3e4116059a0edb1134126047d9e5ebfa1619b6180153cdc8390e6e36c375a179 from block #259156, one of the blocks in solex's analysis. That transaction has one input, and 41 outputs. Now for the purposes of determining how many transactions Bitcoin can perform per second, are you going to count it as one transaction, or more than one? solex is counting it as one.

As transactions become more expensive per byte people are going to use all sorts of techniques to make transaction size smaller. For instance you can combine transactions together with other parties; each transaction includes a 10 byte header. If you get together with 20 other people, you've saved 200 bytes and you improve your privacy because you've mixed your funds with those 20 other people.

The absolute minimum transaction size(1) is for single input single-output transactions. They are 192 bytes each, 182 if transaction combining is aggressively used. 1MiB/10minutes * 182bytes = 9.6tx/s

Big eWallets services like instawallet will be able to get much closer to that theoretical limit than other services simply because they'll have a wider range of txouts to chose from. We may even see agreements between services to use each others wallets just to optimize fees, with something like ripple used to settle imbalances periodically; if off-chain transactions become supported, it's quite possible even day-to-day users will be running software that does stuff like that automatically.

1) Minimum signed transaction that is. The technical minimum is 60 bytes, but such transactions are spendable by anyone and thus offer no security.

The Intel/AMD stuff isn't secure though yet. While the IBM stuff really does bring the security to the level where your attackers need immense resources, because memory isn't encrypted PC-based trusted computing is still vulnerable to attackers with just a few thousand dollars worth of equipment. There is pressure to make the PC stuff secure for cloud computing, so it remains an open question what is the right approach.

Anyway, implementing trusted computing is the last step for any of this stuff; I don't want to have to solely rely on it.



Who says banks can engage in fractional reserve banking? You can force chaum-token redemption to be recorded in audit logs, and those logs prevent them from getting away with that. The logs themselves can be made public, and making them public still doesn't reveal anything.

Incidentally, this is why I mentioned above that there are probably good technical reasons why even off-chian chuam transactions would still require fees: you want to ensure that proving fraud is cheap, which means keeping the size of the proofs down. I expect that there would be some period in which all tokens are expected to be turned over for a given set of deposit addresses, which limits the total size of any given audit log. Because fidelity bonds themselves are only useful if fraud can be proven, I expect new bonds to get purchased over time to "start fresh".

As for time locking: I expect the tokens to themselves be Bitcoin transactions in some fashion, albeit locked so they can't be used immediately. But that discussion is out of the scope of this forum I think; I'm writing up tech specs like I did for fidelity bonds.



OpenTransactions is basically a toolkit, and yes, I do plan to do more work studying it to determine what aspects of their ideas are applicable to fidelity-bonded banks, and equally maybe they're do the same for fidelity bonds.


Small hard-drives were a huge issue 10 years ago. I can't see people buying multiple harddrives, just to experiment with this new-fangled "Bitcoin thing" The block size would have probably been set to something more like 100KiB, and a year or two in this exactly discussion would already be happening.