I think by "node" you actually mean "miner".  "Nodes" are part of the P2P transaction relay network.  "Miners" are the ones solving blocks.

Nodes don't have any designed-in incentives.  They can't relay bad information (the next node just drops it).  The only evil thing they can do is refuse to relay information for some reason such as DOSing the network, trying to split the network or trying to promote double-spends.  This is basically useless to try since the network is so efficient at propagating valid transactions.

Miners work to earn the generated coins and transaction fees.  They have a strong incentive to be a "good" miner (properly including transactions) because if they don't future miners will not continue the chain based on their block.  Instead they will fork the blockchain from before where you did something bad and continue building from there.  Since your bad block gets excluded, you lose your generated coins and fees and don't gain anything.

The only time it becomes feasible to do something "bad" as a miner is if you control more than half of the hashpower on the network.  Then you can create double-spends and DOS the network.

32-bit doesn't matter much.  Bitcoind doesn't use a lot of memory.

The long download time is because Bitcoin verifies all transactions (computationally expensive) as it downloads the blockchain.  If you want to skip this you can download the blockchain here: http://eu1.bitcoincharts.com/blockchain/

No problem, we'll figure it out.

For windows you may have to do enter, ctrl-z, enter.

Also what happens if you try the file method?

You need to press enter and then CONTROL-D.

 Yes, you can save it to a file and the use the second command I showed.

gpg --decrypt

Then paste in your data, then Ctrl-D (Unix) or Crrl-Z (Windows).

Or: gpg --decrypt <filename

I still don't understand how destroyed fees encourage anything.  Do you mean that they're regular fees given to the miners?




Why not just increase the rewards?

This will cause high inflation when the value rises.  That could work well, although I'd be concerned about what happens on the other side.




That's a pretty big assumption.  Hashes per joule has been fairly stable except during the transition from CPU to GPU.  There is some improvement, but overall it will probably underperform that curve for a while, then leap ahead with the next technology jump.





How do destroyed fees promote security?  Why do you need the fixed minimum and maximum?




What are you trying to accomplish?  A 1% tax on all wealth just causes all coins to increase in value by about 1%.  The QUANTITY held in a wallet will change, but the VALUE in the wallet does not.




And in reverse: You haven't increased the value of anyone's wallet, just the quantity.




In my opinion the cost of merged mining isn't worth the benefit.




Why not merge this with your "Koomey's Law" curve?  Just make the initial curve extra-steep.




I like the priority on transactions.  I suggest making the priority of a new block (sum of chain's (difficulty * total value of transactions)) or (sum of chain's (difficulty * bitcoin days destroyed)).  This will prevent 51% pools from DOSing the network.

Everyone already has a copy of the blockchain.  All we need is a GUI or CGI to read it.

+1 for R.  The language itself isn't anything special; languages like Python, Ruby and Perl are much more fun.  The reason for R is it has an immense library of high-quality statistics functions.  I suggest the rkward GUI to get started.

If you're on Android try this: https://market.android.com/details?id=st.brothas.mtgoxwidget&hl=en

Sooner or later you'll have to learn a lot before you can do something useful with that much data.  

But let me give you some leads to explain what that last thing meant.

Cron is the task scheduler for Unix.  Lots about that here: https://en.wikipedia.org/wiki/Cron

The * * * * * means to run something every minute.

curl is a simple http client.  It grabs the web page and spits it to stdout.  https://en.wikipedia.org/wiki/CURL

> means to redirect stdout to a file.

putting stuff in backticks ` ` means to run the command inside and then put the result on the command line.

running "date +mtgox-%F--%T" outputs:  mtgox-2012-02-16--00:30:53

So the actual command that gets run looks like:

curl https://mtgox.com/api/0/data/getDepth.php > mtgox-2012-02-16--00:30:53

To set up the cron job, run "crontab -e".  An editor will come up, and you paste in the line:

* * * * * curl -q https://mtgox.com/api/0/data/getDepth.php > `date +mtgox-%F--%T`

(I added a -q so curl won't output progress messages on stderr; otherwise they would be emailed to you with every run)

Go install Linux somewhere (you can install it in a VirtualBox VM if you don't have a spare computer), try it out, and let me know if you get stuck.

You don't.  You get the depth as of now, and only a slice around the current price.

To automate it on Unix, create a cron job like this:


That will dump it to a new file once a minute.  Better find another way to store it before you get buried in files. 

Step 1: Fetch https://mtgox.com/api/0/data/getDepth.php?Currency=USD

Step 2: save it somewhere.

Repeat as desired.


For the link:

Changing it would fork the blockchain.  This can be done non-catastrophically by adding support in one version, waiting a while for everyone to upgrade, then having the change actually activate on a pre-determined block number.  People who did not upgrade or who reject the new system will reject sliding-window blocks; people who do upgrade will reject the old-style blocks; the side with >50% of the hashrate wins.  (Realistically this won't be done without a supermajority of support.)

You got it.  Be careful you don't randomly swap wallet.dat files in and out or your balances will display wrong.  Running with full separate data dirs works fine other than consuming a lot of disk space.

No, the sliding window just changes the shape of the effect.  The spike will bump difficulty sooner, but it also makes it revert sooner.  Overall the network averages it out and ends up the same number of blocks ahead or behind either way.

Same here.  He's been off for a couple hours.  I'm sure he has a lot of things to do.

I agree, which is why I said it has to change per code, not per share.

The codes have to be relatively small amounts of value so that you don't lose much whenever you abandon one relay and set up a new tunnel (in case they're not performing well, or you need a new identity), so there are practical limits to the number of shares per code.

On the other side, tracking many small-value codes would be a large bookkeeping operation.

All told I think it's potentially workable, just potentially inefficient.

Yes, I think most of the slide is simply erosion of confidence.  Also note that the volume, while somewhat high, is nothing like what we'd see if there was a mass liquidation.

Rather than speculating more, let me go ask them directly. 

This is true only if you create a new TOR tunnel after you receive each code.  It's possible, but it would be quite inefficient.