Thanks all for the replies!

Dear all,

As I currently understand it, Bitcoin addresses are generated from ECDSA public keys as follows (ignoring any byte ordering issues for the moment):

address = base58(versionbyte + ripemd160(sha256(pubkey)) + hashCheck),
hashCheck = first4bytesof(sha256(sha256(versionbyte + ripemd160(sha256(pubkey)))))

where versionbyte is 0 in the real network and 111 in the test network.

Is there any technical/cryptographical reason why this has to be so complex?  In other words, would the following method for generating addresses have some serious flaw that the above method does not:

address = base58(version byte + first160bitsof(sha256(pubkey)) + crcCheck)
crcCheck = crc32(version byte + first160bitsof(sha256(pubkey)))

Or for that matter, is there any point to sha256'ing the public key to begin with?  i.e., would replacing first160bitsof(sha256(pub key)) with just first160bitsof(pubkey) do just as well?

Thanks!

This sounds like a workable site to host such a thing: http://www.freeforums.org/.

Thanks for the pointers.  I'm usually deeply skeptical of Austrian economics, but I'll try and get a hold of these to see what the data and their arguments are.

That's a genuinely interesting point.  The only one I have heard of is 1870s US, but I don't know enough about what was going on at the time to make up my mind whether deflation contributed to these things, or whether these things happened despite the deflationary environment (don't take this as a statement either way, I genuinely don't know).  Out of context, I can't make up my mind (e.g., there are inflationary periods where investment and consumption have gone down, despite the pull of inflation in the opposite direction).  Can you point me in the right direction to learn about these episodes?

This part: http://www.youtube.com/watch?v=jbkSRLYSojo

Yeah, the second half of the twentieth century just, like, didn't exist.

I've heard an argument like this before, but have never been able to get my hands on real data (I've asked but gotten no reply).  Can you post a link to the numbers that back this statement up?

OK, let's try again:


That was my qualm with your post, save the technical discussions for some other thread.  Your reply was about things cunicula said that you disagree with, not about him being very insulting to undeserving chaps.  Again, disagreement != troll.

Off to bed...

I rest my case.

FOR THE LOVE OF GOD, hugolp!  This is simply insulting.  "Troll" doesn't mean "person who disagrees with hugolp".  Cunicula has consistently posted insightful and interesting comments, observations, suggestions and proposals.  He is clearly capable of thinking outside of the Bitcoin religious sect mentality and contributes far more to the discussions than most other members of the forum.  The only time I've ever seen him lose his temper is when replying to Atlas' and your own grandiose verbal diarrhea, which almost everyone who has a neuron can agree is a net positive contribution to the forum.  I challenge you to back up your statement with evidence of Cunicula ever being "very insulting" to anyone that isn't you or Atlas.  It's absolute insanity that this "troll" nonsense is coming out of a "Hero Member" and "Global Moderator".  If anything, Bitcoin needs more thinking people like cunicula and fewer dogmatic people like you.

The easiest way to know right now that the current setup of Bitcoin is completely suspect is the fact that these kinds of questions even get brought up.  I mean, just try and imagine this office conversation:

Me: Hey guys, I think I've found a way to make our code a lot more efficient.

Office mate #1: Your changes smell like a Ponzi scheme to me.

Office mate #2: I don't know about that, but if you think about the details, it's just self-evident that it is not a multi-level marketing scheme.

A reasonable system would never have these kinds of questions brought up.

Perhaps there are different ways of registering these votes?  The reason why I thought miners might do the trick is that the barrier to entry to mine is not too high, so anyone who wants to register their opinion about inflation rates can start mining and join a mining pool.  Right now, deepbit (the dominant mining pool) accounts for ~50% of new blocks.  I should also add that one might also implement speed limits on the rate at which the target inflation rate can be changed, in the same way that difficulty now can't be increased or decreased by a factor of more than 4 every two weeks.

Originally, I had liked Suggester's old suggestion of tying mining rewards to hash rates, so that the money supply would at least roughly track the number of active users weighted by their investment in the system.  But that doesn't really allow for monetary deflation when it's necessary, and it also ties up huge resources in mining, neither of which seems like a good idea.

I'd be happy to hear of other ways in which the target inflation rate might be determined.  Personally, I would favor something democratic and dynamic over an algorithmic solution, as a way to acknowledge that we're all fallible and can't perfectly predict the future, so we need a mechanism for allowing consensus decisions to be changed.

I can empathize with the uneasiness of money supplies being controlled by central banks (even though, personally, I think the system works reasonably well most of the time).  I've posted some ideas on how to keep some of the "people-control" aspect of the money supply in Bitcoin without having to buy into the deflationary mindset here, and I'd love it if you or anyone else on this thread could spare a few minutes to comment:

http://forum.bitcoin.org/index.php?topic=29252.0

I haven't, have no intention of doing, and said "in the context of setting up a new block chain where the money supply is more flexible".  The underlying technical side of Bitcoin is rock solid, and there are many many people in this forum are thinking of ways of building on *that* without having to subscribe to deflationary economics.

Nice work!  The only glitch I noticed is that the value field in a TxOut is 64 *bits* long, i.e. 8 bytes.  Most other field lengths seem to be in bytes.

I hadn't delved into the details of OP_CHECKSIG before, and hadn't realized it was this complicated.  Thanks for sorting this all out for us!

I've been thinking about these kinds of issues too, in the context of setting up a new block chain where the money supply is more flexible.  Here's a system that I think might be workable, and would like to submit it to criticism from others.

Right now, there is a fixed monetary inflation schedule that we all "agree" on by dint of network effects, and there is no way to realistically change it.  It would be better if we could dynamically agree on how the money supply should grow or shrink.  The block chain is a fantastic tool for building consensus without trusting your peers.  So we could set up something like a voting scheme for what the monetary inflation/deflation rate should be.  Each miner that produces a block would add to it in a new field of the block header what they think the rate of monetary inflation/deflation should be (right now, it's fixed at 50 BTCs per block).  The actual inflation rate would then be the median of the voted inflation rates of the previous, say, 100 blocks (this bears resemblance to how "difficulty" is agreed upon nowadays).  If a block's coinbase transaction created anything but what the "consensus" inflation rate dictates, the block would be declared invalid.  Monetary deflation could then be implemented by forcing the miner to forfeit a portion of the transaction fees (if they don't, the block they produce is declared invalid by the network).  This is how a "transaction tax" might be implemented in a way that doesn't allow free-riders to ignore it.

The reasons I think this might work are the following:

a) In current monetary systems, a central bank rather opaquely decides how much money to create/withdraw, and any money created is hard to distribute without political influence.  While I happen to personally think that this system works reasonably well most of the time, I can empathize with the queasiness that lack of transparency produces.  Having a more transparent decision mechanism is certainly better (although shooting ourselves in the foot with the current transparent system that's transparently dysfunctional is much worse, IMHO).  I have a feeling that this queasiness is an important emotional factor in Bitcoin adoption today.  Voting on decisions about the money supply continuously would allow a decentralized consensus to emerge (dare I say, "letting the market decide").  Additionally, the money created goes to miners, instead of politically connected banks and treasuries, and the miners really are providing a valuable service (securing the blockchain). Additionally, in principle anyone can arrange to receive a part of the money created by joining a mining pool.

b) Using the median of the votes from a large number of blocks prevents all sorts of problems from free riding.  If, say, we were to allow any miner to decide how much to inflate/deflate without needing consensus, then the individual incentive is to inflate as much as possible, which, when unregulated, screws everyone over (cf. the tragedy of the unregulated commons).  By voting and forcing a consensus, you lose the immediate incentive to inflate everyone else away, and can vote on deflating or keeping the money supply steady.  If everyone else disagrees with you, at least you get to partake in the money creation.

c) The incentives are set up to keep investment in mining at a reasonable level.  If the consensus is to keep the supply steady or deflate, then miners that just want to get-rich-quick will be discouraged.  This would make it easier for miners that really want to increase the money supply to be the ones that find successful blocks, but they are forced to put their money where their mouth is and temporarily mine at a loss in order to register their votes for an increase.  This might occur when lots of new users join the network and/or there is pent-up demand for additional money due to increased desire for trade: the money supply should grow to accommodate the additional economic activity they'll bring online.  If, on the other hand, the consensus is to inflate, miners that want to deflate have to put their money where their mouth is and increase their mining activity to register enough down votes: in the time it takes to do this, they are participating in the inflation, which would subsidize the additional investment.  It also forces early-adopters to invest their hoards, lest their value be inflated away, which would mitigate the initial distribution problem.  In all cases, there is no threat that mining will be so discouraged that the security of the block chain is in jeopardy.

What are people's thoughts on these ideas?  Virtues?  Flaws?

I've learned to simply ignore the meandering political ramblings (e.g., Atlas & co), and I agree that this by itself doesn't affect the project in any meaningful way (except, perhaps, scaring off more serious investors/contributors).  It's just annoying, and if the libertarians simply produced a product that I could use without having to have my ear chewed off with their world-domination blather, I'd be perfectly happy to use it.

The portion that to me is really a shame is how, on top of the technically beautiful system for solving double-spending and building consensus on a network that lacks trust, has been layered a cultlike devotion to deflationary/goldbug economics that I *can't* extricate myself from.  I and many others have certainly argued why elsewhere, but principally, deflation seems to me like it will choke trade and investment, and keep Bitcoin from growing into the truly useful backbone for worldwide transactions that it could in principle become.  At best, I see things stabilizing long-term to a low trade volume that's an unhappy equilibrium between hoarders and people who are no longer able/willing to hold their coins; on top of this might piggyback transactions like the international transfer I described that simply use BTCs as a 10-20 minute intermediary.  At worst, I see the project dying off because of this.  This is why the economics that's built into Bitcoin, and not just the technical issues, *do* affect the project.

For the record, what I think (and hope) will actually happen is that some other Bitcoin 2.0 with better economics comes online and outcompetes the current implementation.  Presumably, such a virtual currency would be technically similar to Bitcoin, so that the effort already invested into complementary projects, like your Bitcoin-qt client (which I really respect and hope succeeds) or the exchanges, can be leveraged easily and not be lost.  I think the technical underpinnings of Bitcoin, and their potential to change the world if implemented more sensibly, are simply too good to just die off without them being picked up by someone else.


+1

Fortunately, we have a control experiment for this, when Suggester made many of the same arguments being made today on Feb 18, 2010: http://forum.bitcoin.org/index.php?topic=57.msg390#msg390.  I think his logic was reasonably sound, if not perfect, and many of the things he said have since come through (e.g., speculation and bubble/bust being the main thing driving interest and transactions for Bitcoin).

On a similar note to what CurbsideProphet is doing, I kindly asked the guy that actually runs bitcoinworldmarket.com if he could do a service to the community and tell us on a daily basis what his actual sales volume is (http://forum.bitcoin.org/index.php?topic=28276.msg357205#msg357205).  His original post expressed his concern about loans not being viable for Bitcoin (or any long-term deflationary scenario) and how this would choke business growth (for the record, my posts make it clear which side of that debate I take).  He hasn't taken me up on this, but I wish some other serious merchants would (e.g. spendbitcoins.com).  We can argue all day long about "YES YES YES Bitcoin will take over the world" or "NO NO NO it will crash and burn", but there's nothing like actual data to settle these questions.

OK, I looked into this, and blkindex.dat stores both the index to the blocks and the index to the transactions + a few other things (!!!).  Here's the relevant code that records a block into the index:


In other words, the key is whatever pair serializes to, and the data is everything in the IMPLEMENT_SERIALIZE block of CDiskBlockIndex (see main.h)  That seems to be an index into the blk*.dat file, a block height, a link to the next block on the main chain, and a copy of the block header.  For comparison, the code to store other things into this *same* database is