Well, probably.  The mapping isn't known to be evenly distributed.  But on average, there should be something like 2⁹⁶ keys per address.

P.S.  It is RIPEMD-160(SHA-256(pubkey)) .  Only two hashes, not three.

More likely in my view, is that the report is just fine, but most of the dire implications that we are finding in it exist only in the bitcoin community's collective heads.

+1

I'm not a big fan of Steve's political views either, but his dynamic approach to economics is fucking fantastic.

Ugh.  What power?  That's what I'm asking you.  I'm not asking you to repeat your position that there are magical powers involved, I'm asking you "What power?".

P.S.  It was hardly behind your back.

Just out of curiosity, has MAX_BLOCK_SIGOPS always been defined as a fraction of the block size?  From the P2SH debates, I remember the number 20,000 which is what you get when you perform the division, but I don't remember the division.  And as I recall, it was somewhat important, as a change to it could potentially cause a hardfork.  And I can't find any documentation on it other than the source code, so I was wondering...

How can they "edge out companies"?  How?  What magical powers do you imagine this foundation possesses?

(Caveat: your answer must not assume that everyone is as dumb as you)

Sorry, but you are just totally wrong.  You are using a static view, which won't work.  In the real world, the lender will spend at least one dollar back into circulation in order to capture the value that they earned through the loan, and when they do, the borrower can acquire it and make the final repayment.  If the lender fails to do this, then the dollars don't generally circulate, and they will have no value, which would make the loan pointless in the first place.

For people seriously interested in this subject, Steve Keen has done a lot of work on dynamic nonlinear economics.  Read some of his papers and watch some of his videos.  He'll fix you right up if you pay attention.  At least a couple of his videos cover this topic in great detail.  He shows that it is very possible to have a functioning economy (including a loan market with interest) with a fixed amount of currency.

Unless you are a jeweler, gold and silver aren't really capital in this sense.  They are money, which can be used to buy the capital.

This may be unsafe.  Be careful.

Signature verification in ECDSA has an interesting quirk.  When you are validating a message, you end up with the public key of the private key that must have created the signature.  For safety reasons, the bitcoin client requires that you provide an address to the verification function, which then finds the public key from the message and the signature, and then returns true or false depending on whether or not that public key hashes to the address provided.

Because signatures include a random component, an attacker can easily keep trying until they find a valid signature for an address that "looks like" the real address.  For a human typing on the command line, this means that it is very unsafe to take just the message and signature and return the key.  If you do this, sooner or later, you will be fooled and you will think that a signature was valid when it really wasn't.

However, think about this other usage...  You have a website, and you don't want to make people register for it.  You just ask them for a bitcoin address that they will sign their messages with.  You stash that in your database, and then whenever commands come in, you take the command and the signature, and find the address that signed the message, then look that address up in your user database.  If you find a match, you know that the command came from a real user, and you know which user.  Obviously, this system won't be fooled by a second address that merely looks similar.

What would this look like?


In the third usage, verifymessage takes a literal question mark character where the address should be and returns the address corresponding to the message and signature.  This example was taken from https://ecdsa.org/bitcoin_URIs.html, just the first google result I came across with a valid message and address in it.  The first command is with a bogus key that I made up, and the second is with the correct key.  Together they show the safe (normal) behavior of the client, which is to require a proper address for verification, and return simply true or false if that key matches or not.

This functionality was left out intentionally to avoid users doing unsafe things.  I agree that this can be dangerous, but I don't think that it necessarily has to be.  So I'm just going to drop this here and let it sink quietly into the depths of Google's memory.  If anyone thinks that this would be useful for them, they can contact me for a patch.

Oh, and if you can follow EC math this can be done fairly easily outside of bitcoind too, and several devs have expressed the opinion that it should remain outside of bitcoin.  Someone was nice enough to show me code for it in Javascript, but I'm not sure if that person wants it distributed or not, so I'll let them pop in to provide the link if they want to.

Just FYI, fractional reserve was invented for gold.  Goldsmiths created the practice by issuing more warehouse receipts (bearer certificates) for gold in their warehouses than they actually held in gold, and those receipts (certificates) were already circulating as money because they were much more convenient than actually fetching and hauling gold around.

In practice, this is pretty safe, since most people won't want their gold all at once.  Keeping healthy reserves will reduce the chances of being unable to meet a withdrawal request (a bank run) to whatever level is deemed appropriate by the bank.

The real innovation of the Federal Reserve system is that the Fed is able to create dollars out of thin air and can lend them to member banks instantly, making bank runs entirely impossible.  This really just passed the danger up the chain though, leading to the closing of the gold window when France (and friends) attempted to redeem lots of dollars for gold.

In the bitcoin world, fractional reserve is still totally possible.  It is just risky.  A bank that does it faces the very real chance of not being able to make a bitcoin transaction to back up a depositor request.  Banks can mitigate this risk to some extent with pooling and interbank lending agreements, but that exposes the pool to a much lower chance of a much worse event, and it will be impossible to eliminate the risk entirely.

The point that you are missing is that the capital was saved in advance either way.  Credit just changes who has access to it, and under what terms.  Equity investing does the same thing.  Neither one is required for growth.

And I disagree totally about the length of time it takes.  Accumulating the capital takes the exact same time either way.  Again, credit does not magically cause capital creation.  It can change the way that capital is allocated, but it doesn't create it.

Oops, this is where you go wrong.  Growth does not require credit.  Growth requires saved past production (commonly known as "capital").  Credit just means that it isn't the grower's capital.  Manipulation of credit also does not magically make that capital spring into existence.

The debt system allows businesses access to more capital than they would have access to on their own, and it allows savers more access to growth than they could do on their own.  Equity investing is another way to do this, and it offers different risk/reward profiles.  Having both gives both sides more options.

The ship for "preventing" such accusations sailed a long time ago.  At this point, I want the foundation forums to stay totally private and secret just for spite.

Sorry for resurrecting this ancient thread, but I figure it is already in obsolete, so no one will care.

For some reason, I started thinking about this again.  I had forgotten the part about the Stirling numbers, but I had the "well, duh!" moment when I realized that 6^12 is only about 2 billion, and I might maybe be able to find some sort of computing device capable of iterating all of the combinations.

The only information that a node gets about the origin of a block is which of that node's peers sent it first, not where that peer got it, not where it was made.


Meh.  It isn't like deepbit hasn't hashed millions of other transactions over the years.  And because of the timestamp flex, you don't really have any idea how much time deepbit's system had to accumulate new transactions between the previous blocks, and the getworks that resulted in these blocks.


It matters in exactly the way that I described.  A block with a timestamp too far into the future isn't valid, and a block with a timestamp older than the median of the last 11 blocks isn't valid.

Blockchain.info isn't making any effort to figure out who made the block.  They are reporting who relayed it to them.  Sometimes those are the same, but other times, they are not.  Pieter mentioned that very early in this thread:


On timestamps, the network restricts them to be not more than 2 hours into the future, and not earlier than the median time of the last 11 blocks.  The 2 hours/future thing actually operates on the adjusted time, not the system time.  I'm not a big fan of that, but not everyone shares my OCD regarding NTP.

After getting two reds, the chances of getting a third is 0.5.  But you'll only get two initial reds 0.25 of the time.  The product is that one time in eight you get three reds, exactly what you'd expect before seeing the first two colors.

If the host doesn't know where the car is, he'll pick it half of the time if you haven't already picked it, and never pick it when you have.  When the host doesn't know, you have a 1 in 3 chance of picking the car correctly the first time, and switching doesn't change your odds.

There are 12 possible outcomes, including some duplicates.  Say we rename the doors (after the game) to ABC, where A is whichever door had the car, and B and C had goats.  The outcomes are (the first letter is your choice, the second letter is the hosts choice, the third letter is which door you end up with):

 1   ABA   see goat, stay, win
 2   ABC   see goat, switch, lose
 3   ACA   see goat, stay, win
 4   ACB   see goat, switch, lose
 5   BAB   see car, lose
 6   BAC   see car, lose
 7   BCB   see goat, stay, lose
 8   BCA   see goat, switch, win
 9   CAC   see car, lose
10   CAB   see car, lose
11   CBC   see goat, stay, lose
12   CBA   see goat, switch, win

5, 6, 9, and 10 are moot because once you see the car, you've already lost.  You can still switch, but there isn't any point.  1/3 of the time (4 of 12), you'll lose when the host opens the door with the car.  When the host opens a goat (8 of 12), in 2 of those cases, you win if you switch (7/8 and 11/12), in 2 you lose if you switch (1/2 and 3/4).  Your odds are the same either way, 50% from when you get to that point, and you get there 2/3 of the time, for total odds of 1 in 3, exactly what you'd expect up front.

When the host knows where the car is, he reveals part of that information to you when he opens a door, which changes the odds.  When the host doesn't know, he doesn't have any information to reveal, so the odds can't change.

Because we don't want to make rules like that.  The reference client makes up the bulk of the network, so any rules in there carry a lot of weight.  Until the network is more diversified, the devs are cautious about such things.

Miners should be allowed to include or exclude transactions according to whatever rules they want.  And nodes should be allowed to dislike certain blocks, to some extent.  By putting rules in the reference client, the devs would be forcing their rules on everyone, and they don't want to, and simply won't do it unless things get pretty ugly.

Blocks with no transactions are still doing part of their job, just not all of it.  And they are still valid.

The idea that I proposed, in case you are interested, is to keep a timestamp on transactions in the memory pool, and to check them when a new block comes in.  If the new block doesn't include some fraction (10%?  25%? ) of the transactions that you knew about at some time prior to the block coming in (1 minute before?  5?  10? ), just quarantine the block until another block comes in, assuming that there was a sufficient number of known transactions (50?  100? ).  The new block will either be a better replacement for the antisocial block, or a block that builds on top of it.

This way, miners would have an incentive to include transactions, because more transactions means that a larger fraction of the network will relay your blocks, spreading it quicker, reducing your chances of getting orphaned.

Note that this proposal is actually fairly complicated, and no one would want to have to actually write it, nor maintain it.  It has the advantage of not centralizing control, but that's about all it has going for it.  Other solutions are possible, with varying combinations of complexity and ease of implementation, and the devs don't want to do any of them unless they actually have to.

When I started with bitcoin, difficulty was around 120,000.  This latest jump is roughly three times the entire network power from like less than 18 months ago.  Not bad for two weeks.

Not really.  There are actually several ways to counter this if we ever need to.

Not too long ago, there were a lot more of these no-transaction blocks and there was speculation that it might be a botnet doing them.  If it is a botnet, the rise of ASICs over the next few months will pretty well kill them off.  If it isn't a botnet, we can make it costly to be antisocial if we really need to.