Well, for all we know he's lying about what the trick actually was. 

Read my top few messages.

While you make a good point, in the scenario where you don't have a full copy of the UTXO set it's irrelevant anyway. Without that UTXO set you just don't know what is or isn't a valid transaction, so mining is pointless and validates nothing.

It's not quite true because you're implying there wasn't a limit. There was a blocksize limit all along, it's just that Satoshi decided it should be reduced from 32MiB to 1MB.

Look at the early commit history of Bitcoin sometime; Satoshi made really misleading comments all the time hiding major changes.

That's not quite true. Version 1.0 didn't have a 1MB limit, but instead used the same 0x2000000 byte, or 32MiB limit, used for any serialized data. Satoshi later added MAX_BLOCK_SIZE so that miners wouldn't create blocks bigger than 1MB, but larger was still accepted.

Finally the hard limit was reduced by Satoshi to 1MB in commit 172f006020965ae8763a0610845c051ed1e3b522 The commit comment is deliberately misleading: "only accept transactions sent by IP address if -allowreceivebyip is specified"

The very idea that we'll just go off an change the limits without a demonstrated problem is why it's political. With the current 1MB hard limit, a 250KB UTXO limit makes sense. (what I would have proposed) Increasing the hard limit in exchange for a UTXO limit still runs into the more important issues about ensuring that miners can operate on low-bandwidth connections.

"no ambiguity" <- that's exactly what failed. In v0.7, db.h, there is the following line:


That means, create a CTxDB class, that extends the CDB class. That class is from an external library. What's CDB? What version? What does it do? All this stuff is ambiguous. Yet just "include every external" library doesn't work either; how far back do you go? While not as issue now, with really large blocks even subtle stuff like performance differences between different hardware implementations are can cause forks even with identical software.


Believe me, the developers understand the importance of the problem very well. As an example Pieter Wuille and others have been working to prevent OpenSSL differences from causing a fork with IsCanonicalSignature() and similar. I don't happen to agree with Gavin on everything, maybe even not on most things, but I can agree that he has been taking his roll in pushing testing and stability very seriously since he was hired by the Bitcoin Foundation, and for that matter, even further back than that.

There aren't easy solutions to specification problem, and I really think that writing yet another specification in addition to the imperfect one we already have is currently a waste of limited manpower. It might always be a waste of manpower - Bitcoin is in uncharted computer science territory with its extremely strict requirement for consensus.

For an implementation of this designed for busy services could simply take advantage of the slowness of flicker itself to keep track of time roughly. Just assume every flicker call takes t time and increment your current time variable.

Don't get me wrong, I think there should be a specific UTXO growth limit just like there is a blocksize limit. However js2012 described it as a solution that would solve the problem totally, which it won't.

If the issue was less politically controversial, not to mention technically risky, I'd propose a patch creating such a limit for the May 15th hardfork. As it stands there's no way it'd happen though.

Specifications aren't magic; they're just words on paper. I can put anything into a specification, but it doesn't magically make code actually follow the spec. I can also take the specification and write tests, but again, the tests don't magically make the code follow the specification.

Before commenting further on the topic you need to read the Bitcoin sourcecode yourself. If you can't read it, you have no business commenting on software development anyway. If you can, you'll find that while it isn't perfect and could use some refactorings, all in all understanding the intent of the different parts is fairly easy and thus the code itself acts as a perfectly good specification.

The idea isn't new. It also doesn't help much because the UTXO growth limit has to scale with the overall blocksize limit or it becomes difficult to reliably get transactions confirmed. Since it has to be a significant fraction it still doesn't solve the underlying scaling problem, only buys you time temporarily.

Or a non-inflationary money supply.

I believe in context "using the chain" refers to the act of using the chain for transactions directly rather than using an off-chain transaction system. Just following that quote was:


If your business model relies on on-chain transactions and is threatened by high fees you have every reason to petition for change in a variety of ways, including to the foundation.

Relevant IRC:


http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12#l6304349

I like the term "hashers" myself, short and simple.

I'll refer the religious capitalist wonks to my earlier post on the nature of Bitcoin:

Cool! Also I'm seconding jgarzik's demand to see a demo. 

Plot for a cyberpunk story: The UTXO set "hording" happened, followed by a tech revolution that suddenly made storage space/network bandwidth a lot cheaper and P2P sharing of it feasible again. Given the enormous incentives remote hackers, physical thieves, and insiders launch an all-out attempt to steal that UTXO set data. Whomever succeeds has done something not dissimilar to stealing the gold out of the national reserve, albeit in this case the "gold" is a constantly perishing commodity and the attempt would also require a co-ordinated launch of enough hashing power to make the new UTXO set actually useful. (maybe done by remotely hacking water heaters around the world?)

Well this is why I'm perfect for the job: it's already clear to many (if not all) that I am hell-bent on destroying Bitcoin and likely any other crypto-coin.


Ha. I remember a discussion I had with someone on IRC awhile back where we were joking that we should port SatoshiDice to one of the alt-coins to kill it in a flood of spam: "Of course, we couldn't just run bots, we'd have to let anyone make real bets. We could even fund the effort from the profit generated! In fact, it might kickstart the alt-coin's adoption, raise the price, and before long we'll be implementing off-chain transactions to ensure we don't kill our golden goose!"


Of course. An easy task probably given that there aren't many differences between Litecoin and Bitcoin technologically.


Re-read my post. I'm well aware the economic majority argument and wrote it specifically to demonstrate how it doesn't always apply.


While we're at it consider how database protection laws (IE "copywrite-like" for databases) could apply to blockchains. Keeping a UTXO set will be very expensive, so it's easy to see how full nodes with that data will want to find some way to be paid to maintain it. Directly paying for access is one option for instance, but the other is for miners to offer free access. For the latter scenario even if the miners don't ask for exclusivity contracts in return, IE you agree to only send your transactions to this mining pool, there are good reasons for a miner to try to ensure that no-one can do a whole-sale copy of their UTXO database, as allowing that, even if paid for, allows for competitors to start up. Violating those agreements can be seen as violating database protection laws in jurisdictions where they exist, in addition to violating the contracts themselves. (note the very similar concepts outlined in the "red balloons" paper)

The transactions included with each block form another source of UTXO data, albeit a source that requires one to stay online constantly. Now you have yet another perverse incentive: if a competitor experiences some downtime for whatever reason you have no reason to want to give them the UTXO data that allows them to start mining again. Of course, they have the option of trying to pay for it, but ultimately the mining pool as a business has to ask the question "Do you accept $x from a competitor, when if you don't accept the payment they may be forced out of business?"

Finally when you create a block you do have an incentive to distribute the transactions associated with that block so as to allow your competitors to build upon that block. But your incentive is for only >50% of the hashing power to have that data, because it's that >50% who will inevitably create a longer chain. Of course, including measurement errors and variance you'll want to target a higher percentage, but the point is miners have incentives to ask other miners for proof they control a certain amount of hashing power, and just not bother relying solved blocks to players who only control a tiny amount of hashing power. Again when the number of miners is sufficiently small this can all be done as legal agreements backed by contract law and database protection laws.

tl;dr: A rational miner has a incentive to deliberately withhold transaction and UTXO data when the cost of maintaining that data is high and the overall number of miners low, and that incentive perversely leads to even further centralization.

I'm a pragmatist. If I wrote a patch that replaced transactions with any newer one if the total fees were increased, it would never get into the reference client.


As an aside you must require a limited resource to be expended to broadcast a transaction on the network for DoS protection. This also implies that the network bandwidth required to run a full node will now be an even further higher multiple of the "blockchain bandwidth" than it already is. How to price that properly is an open question.