Nethack.

Eggs Ackley.  Satoshi did something nearly impossible; he spearheaded a major development, worked with people over an extended period of time, managed to do it without leaving a single shred of evidence linking to the government's name for him, and GOT AWAY WITH IT.  "Satoshi Nakamoto" is the single hottest nym in the world in terms of making trouble for anyone who can ever be proven to have been the guy who used it.

Why the hell would he ever use the single hottest nym in the world again?  It would just give people a chance to catch him.

I say again.  We are all little fish swimming around in an aquarium, constantly watched.  But Satoshi knew the whole system, worked around it, and  HE GOT AWAY WITH IT.  Getting associated with that nym now would blow the whole effort he put into keeping it a secret, and if you understand how much surveillance we're under you know that was a HELL of an effort to do.

bitcoind or bitcoin-qt will have lock contention fights over the database and, yeah, you probably can't get more than about 3 clients being productive at a time (depends on the I/O capabilities of the machine how long the locks last). 

Part of the problem is that lock for reading shouldn't prevent another lock for reading -- but the clients assume that they are locking for both reading and writing.  If they got read locks instead, and no client had a write lock at the same time, they ought to have much better performance.

LOL!  You're SO right about that.  The sun is likely to be seen rising in the East tomorrow, too, and it's a safe bet that somewhere a cat will probably have kittens.


Here I think we disagree.  If there's a moment when a lot of people want to use it, and it takes the load, then that moment is not likely to end.  If that moment arrives and it collapses, then that one is over and another moment is not as likely to arise.  It does little good to build the system people needed, two years after they need it.

So I'm of the opinion that the Bitcoin network needs to stand ready to take a large load, within at most a few weeks after the load starts ramping up, or else it squanders an opportunity to become part of the world's infrastructure.  Another opportunity may arise, but then again it may not.

I just don't think we can afford to wait for sidechains. 

Sidechains require some substantial development and a whole lot of thought given to attacks and testing security.  Someone might be able to come up with something that "works" - ie, you can cryptographically prove transfer from one chain to another -- in a month or two, but it could be a couple of years before we've really considered it hard enough to be confident that we have thought of and effectively countered the security risks. 

The thing with side chains is they are COMPLICATED.  There are a dozen new protocol features we'd have to get right, and the sequences available among those dozen, plus the already-existing, give potential attackers hundreds, or even thousands, of things they could try.  And we have to sit down, and go through those things, and say, okay, what could an attacker do with this sequence?  And what would he have to gain?  And what would it cost him?  And what would it cost the node operators?  The miners?  The users?  And how would the network react to the attack?  And if that's unacceptable, is there an easy way to limit the risk?  And if there is, can we limit the risk without impairing the functionality of some other part of the protocol?  And do the miners' motivations balance out here to make sure the side chains get decent mining coverage for security?  If they're merge mined with the main chain, how does that affect them? 

Supporting side chains is a hell of a lot more work -- design and security work, I mean -- than just getting them running.  I think, in the best case, sidechains that get deployed without a security failure or a major attack, and which don't fizzle out due to lack of mining, are a couple years away.  The dev work is relatively easy; but the design work and the security work will take that long.  And so, for now, we are discussing something a lot more simple that exposes very little new attack surface. 

A limit increase is relatively simple.  It gives an attacker exactly ONE new move, the attacker has to have major infrastructure committed to do it often enough to matter, and the fact that a limit still exists restricts the amount of damage an attacker can do with that move. 

Heck, I'd go with this.  Fixing it so the block size can be no bigger than 10x the median of the previous thousand blocks (plus some minimum to prevent the "sticky zero" of that simplistic formula, which might be relevant if the network ever has to restart) would do it for me.  It would make me happier than the current proposal, in fact.

But I guess it comes down to three things, for me.  First, I don't believe that the developers are clueless monkeys or lazy-asses who won't get around to doing anything, and I think characterizing them that way is kind of insulting.  Seriously, have you been reading the v0.10 source code as opposed to the 0.8.x?  A *lot* of work has been done.  This is not a bunch of lazy-asses that will keep kicking the can down the road.

Although, if they have to deal with the likes of this argument every time a fork is needed, failure to get anything done won't require lazy-asses or clueless monkeys.  It'll just require people who lose patience and quit when getting stuff done turns into an acrimonious shouting match.

Second, even though I don't believe that the 20MB + exponential growth for 20 years proposal is absolutely the best possibility, I *FEAR* this discussion getting so bogged down with "the perfect being the enemy of the good" that no block size limit change at all happens.  The way I see it we've got to do something about the transaction rate, and this is, by far, the most developed proposal with the most momentum behind it and the least technological risk, even if it there are other, probably better, things that could be done.

Third, I simply don't believe in your threat model.  Suppose a miner today tried to fill up 20MB blocks with bogus transactions.  He couldn't do it as  a mining pool operator, for a bunch of reasons to do with protocol and logistics.  First of all it would increase the bandwidth costs of the miners by about 40-fold, even when not getting blocks.  Second, the propagation delays that apply to all miners submitting bigger blocks apply to pool operators at least three times, not just once, meaning a *LOT* of missed blocks, not just a few.  So it will make them noticeably less likely to get blocks.  And third, there are other mining pools that are easy to switch to and don't have those disadvantages.  So if somebody running a mining pool tried your attack, I'd expect miners to stay away in droves.  

That leaves the hash farms as the only realistic candidates for supersizing blocks, and the hash farms have very limited time to make ROI on a major investment in rapidly-deprecating mining equipment.   If a hash farm tries your attack, they'll have to economically justify the money lost, and I don't think the numbers work.  So, even if someone is attacking, and even if for some economically insane reason they are attacking with enough power to get a whole block every day, (which NO HASH FARM can do at this time) they're only adding 20MB/day to a block chain that is currently on the order of 85MB/day.  It's annoying, but it's costing them to do it, they can't sustain it for very long, and as an attack, it is not a disaster that the nodes can't handle.

The proposal on the table is not to scale the block chain at the rate of anticipated growth in Bitcoin usage as such -- which you and for that matter I would prefer.    What it is doing is scaling according to the ability of exactly the same attack you're worrying about to create a more-than-just-annoying problem.  It's much easier (though still unreliable) to make projections about the availability of bandwidth and what amount of bandwidth will constitute a serious problem, than it is to predict the timing of Bitcoin's adoption by the mainstream or the coming and going of Bitcoin-adoption fads.   Nobody's really trying to predict the amount of Bitcoin use or the moment of its adoption by the mainstream here; they're just putting a limit on how much damage your attacker (the one I don't really believe in) can do, and the limit scales at the same rate that the resources necessary to deal with it scale.

Did anybody else notice a large sale of Bitcoin, spread across essentially all major marketplaces, at about 2 PM on Sunday 22 February 2015?

Can anyone think of a single reason why somebody with that much coin to sell wouldn't have waited for a weekday when the markets are deeper?  I mean, unless the timing is deliberately chosen to move the price by the maximum possible?

Nothing prevents people from releasing source code for a key generation technique different from the one they are actually using. 

Never.

     EVER.

          Use a key generated by someone who is not you, to store your money.

Yup.  But that's not what anybody advocated, so why are you bothering to say it would be bad?  

The proposal is not indefinite exponential growth; it's exponential growth for 20 years.

Nor does it seem particularly inaccurate to me; as I pointed out already.  

Finally, there is no such thing as a course of action to prepare for the future that is not based on some form of extrapolation or prediction.  But that doesn't mean failing to be prepared is a good idea.

And I still have no idea what miner would deliberately lose money by taking block size up to the very limit using bogus transactions, or why they would try to.  We're talking these days about people running actual businesses that they have invested major resources in and want to see some ROI.  This is not just set of randoms that's going to contain trolls who came along just to wreck things for lulz.    So I'm just not seeing the immediate threat model of a ridiculously enormous block-chain that you claim to see.

I think he's just being pissy about not knowing who wrote the code.  He'd like for there to be someone to blame in case of a problem, and the "satoshi" identity just doesn't work for him.

If the population of Earth in 2035 is ~8 billion, that's 2 bytes per block, per person. 

Given 144 blocks a day, that's 288 bytes per person, per day.  If everybody uses the block chain twice a week or so, the block size proposed for 2035 should be adequate. 

Since most people don't do money orders, remittances, or savings-account transactions that often, honestly I think that ought to suffice for "ordinary" use by ordinary people, even with a very high rate of adoption.  I mean, some will be using it for every cuppa coffee, and some won't be using it at all, but it averages out at what I'd think of as a normal rate of usage for complete mainstream adoption.

I think the FBI is facepalming right now because it is auctioning coins in a $250 market when it got them in an $800 market and sold the first batch in a $600 market.

I think they will facepalm again in the future when they've sold these and the market swings back up.   

Change in divisibility should have an effect only if the old, or new, divisibilities are on different sides of a stable equilibrium.  One satoshi is presently far below the fees of a single transaction.   Whatever equilibria exist, I would expect none to be less than 1/10 x typical transaction fees.  So a change in divisibility to any other minimum unit also less than 1/10 x typical transaction fees should have no measurable effect on value.

Just an opinion, I guess - but Id be astonished if there were any effect.

Cryddit

There is a fundamental problem, really.

Either a user keeps track of his own key, or the web wallet/exchange/whatever that has the key can Goxx him.

But if he keeps track of his own key, then he has to keep it secure.  And most people are not willing or able to do what it takes to keep keys truly secure on their own systems. 

I don't think he/she/they are stupid enough to keep that amount of btc forever.

I think a minimum and maximum block height are worthwhile additions for a transaction record.  

The suggested maximum block - "Absolutely do not include this transaction in a block later than N" - is an excellent way to set up a transaction so that you know when it has, definitely, FAILED to be included in the block chain and you can do other stuff with the inputs.  

It would be very valuable (as would a corresponding minimum block  - "Absolutely do not include this transaction in a block before N") - to make a certain number of nonstandard transactions ( protocols and exchanges) a hell of a lot simpler and faster (and easier to understand and explain) if we had it.

But I'm not going to spearhead any attempt to hard fork in order to get these things added.

I've thought from time to time about producing a bootstrap.dat that extends to the current chain depth; the one that people are still getting off of the torrent is now over a year old.

But now we no longer need it.  With version 0.10, we now have headers-first download, so it no longer matters.  It's now about as fast to download using the bitcoin client as it is via bittorrent.

The penny argument was why the smallest unit is no bigger than 1e-8 bitcoin; On the other side of it, there is also an  important reason why it couldn't be smaller than 1e-8.  IEEE "double" floating point format has 53-bit precision.  So if the total number of units had been too much more than 21e14, then people doing math with doubles could get wrong answers due to rounding errors.

I didn't think this was particularly important at the time because using a float format to represent money units is STOOPID in the first place.  But apparently it's more important than I thought; In several scripting languages (cough Javascript cough) it turns out that it's actually a bit difficult to use anything else.  


EDIT:  I got some of the numbers blatantly wrong the first time I wrote this... 

I set aside a day every year as an observation to the memory of the person who invented blankets.   Seriously, blankets are awesome.  Give me a choice between blankets and wheels?  I'll take blankets. 

John Paul Jones, well known as an American revolutionary, is known to be a pseudonym.  Nobody knows who he was before he emigrated from England; probably  some kind of petty crook.

On the intellectual side of things, I suppose in another six centuries we'll still be arguing about who wrote under the pseudonym William Shakespeare and who coded under the pseudonym Satoshi Nakamoto.

 Has Grigory Rasputin ever been definitively associated with a birth record?  Didn't he appear out of nowhere claiming to be some hundreds of years old? 

I don't think Satoshi's keys are or have ever been in the hands of the sort of person who could just "lose" them.

However, there are good odds that the inventor of the "Satoshi" identity is the kind of person who could make a hard decision and delete them once and for all when he decided that job was over.

It's very simple; if you don't want to be tied to the identity, you have to make sure there's no evidence.  Not even in your own possession.  That means giving up the money and not taking credit for the work, but then I've seen no evidence whatsoever that "Satoshi" ever gave a crap about personally having the money, or for that matter the credit.