Curses!  I wanted pi.  Guess I'll have to settle for:

27.1828183

Also, the M/D/YYYY date representation makes me cry.  OP, please consider switching to the international standard for date representation.

Those places exist in great numbers because of the insane fees they charge.  Bitcoin is going to kill them, in a very personal and targeted way.  In theory, they could continue to exist by still charging the same crazy fees on bitcoin transfers/exchanges.  But, since bitcoin takes away all of the transfer risks, every shopkeeper should be willing to do small transfers and exchanges for a tiny fee for any random stranger off the street that is willing to wait an hour (or so).

So, don't expect the parasites to be much help, since doing so will hasten their own demise.

If there was a right way to do it, everyone would do it, and then it wouldn't work.

Trailing stops are uncertain.  None of the exchanges that I'm aware of can actually do them.  You can do it yourself with a bot, or with a meta-exchange, but you risk a fast move blowing past your price, and latency says that you can't remove that risk.  I think Bitcoinica does trailing stops, but they are the counterparty, so they have to charge you extra for their latency risk.  But, they may be your best bet, for now, because...

You can't really hedge properly, because we don't have an actual future or forward market.  And at this point, I don't think that anyone in the world even remembers how either of those used to work before leverage.  I've done a lot of work on futures before, and it isn't trivial to do it right, and it gets worse when you need to minimize trust.

Until someone adds a new RPC call that actually is dangerous.  And why not add some?  The messages are signed and secure.

A system that is 90% safe is a trap waiting to spring on the first guy that forgets about the other 10%.

No, I get it.  What I'm saying is that you need another function, json_encode_canonical() such that canonical_data = json_encode_canonical(json_decode(arbitrary_data)) and you need to implement it the same way on all platforms, so that when you calculate digital_signature(canonical_data) you are always doing it on the same data.  The json_encode_canonical() function can even ignore fields that don't factor into the signature.


Timestamps have their own problems.  Either the clocks need to be synchronized very well, or you need a window of validity, but that window of validity is also a window of vulnerability.  You'd think that synchronizing clocks would be an easy assumption, but it turns out not to be at all.

For the usual case, you don't care that multiple messages might be equally valid.  The signature is for "this message", not for "any message bearing the same content as this message".

If you are worried that a proxy might replace the message with a message that is different but equivalent, then you need to have a canonical form, and you should only emit the canonical form.  When the client receives a message, it must convert it into canonical form before checking the signature.

As for the ID, don't leave it out of the signature unless you enjoy replay attacks.  Just force the client to make it globally unique.  There are already well established techniques for doing this.

I guess we should thank the_joint for making all of these contests read like a EULA with every possibility covered.

I'll take tax day, April 15th, 2012.

And since 9 or 10 people other people also "own" that exact same gold bar, the EFT/COMEX is always very careful to keep it well guarded.

Add a "signature_algorithm" key to the response.  Also, allow the request to specify a list of acceptable algorithms, like {"id": "1234", "signatures_accepted": "ecdsa: SECP256r1, SECP521r1; pkcs 1", "firstbits": "1payBTC"}  If the server can't provide a signature that the client is willing to accept, throw an error response.  Sadly, this is a damned if you do, damned if you don't situation.  If you lock in to a single system, you are stuck with that system and the hassle of replacing it later.  If you make it extensible, you have the hassle of actually supporting multiple systems.  (See IPSEC)

As for actually calculating it, there are two ways to go.  In a binary protocol/format or when the length of the signature is known in advance, it is common to construct the response using zeros to fill in the signature field, then calculate the signature based on that, then overwrite the zeros with the actual signature.  In a text stream like this, I would build the response without the signature key and value, then construct a new response that includes them.  Or just insert them, modern languages have no problem chopping and splicing strings, and C programmers already have lots of practice doing it the hard way.

Exactly.  Firstbits can only be safe if the person doing the lookup has the full block chain, AND if the address in question is buried deeply enough in the chain that a reorg can't touch it.  If either of these are false, you are vulnerable.

I'm not sure how widely known that second part is, but since the point of firstbits is to have addresses known in advance, the odds of getting a fresh (aka vulnerable) one are already small.

Don't forget that an attacker doesn't need to wait for a spender to come along before he starts looking for his own bogus addresses that look like firstbits matches.  Since the point of firstbits is for the address to be well known in advance, he can start compiling his database now, and then wait until he sees a transaction to one he's already found before he attacks.

Personally, I think that the inevitable proliferation of chainless light clients is going to kill firstbits, for exactly these reasons.  There is just no way to make it safe without checking on your own fully chained node.

By the way, when I was researching this sort of thing, I came to a couple of surprising conclusions.  First, unidirectional RPC will work totally fine, it is never necessary for the server to initiate, and no state is ever needed.  Second, there are only a few RPC calls missing from the standard client that would be necessary to fully support light clients.  And third, as long as the light client is creating the transaction internally and using the server as a dumb relay, a malicious server can't do any real damage, it can only cause some light mischief.  (That third one is only valid from the spender's point of view, of course.  An owned server is still a big problem for the owner of the server, just not for other people that use it.)

Eww.  Websockets are only useful when you have no other way to start a connection.  After that, it is just an obfuscated TCP socket.

Agreed.  He goes on to list a bunch of failed electronic currencies from the last 15-20 years.  Hopefully he'll realize the one critical factor that is different between all of them and bitcoin.  Watching it now to see how it goes.

Spoken like a true Open Source-er!

Free Software and Open Source are different things, with different goals.  My apologies if you understand the difference, but your post strongly suggests that you do not.

And no, the license doesn't kill your project (or any other, really).  You just can't use this software for it unless you comply with the terms of the license.  You still have the option to do all of the work yourself, or pay someone to do it for you.  You even have the option of negotiating the purchase of a special license from Genjix if you want.

And no, I have no idea what Genjix's stance is on Free Software vs. Open Source.  I'm personally a big fan of Free Software, so I hope he is too, thus I hope that he retains the AGPL license.  But as the creator of the software, the decision on license terms is entirely up to him, so if he feels that this is a commodity library, destined to be one among many, then GPL, LGPL, or something else will be entirely appropriate.

Can I ask what you hope to gain by having multiple wallets?  Whatever it is, multiple wallets is almost certainly the wrong answer.

I still prefer my idea of adding exponential difficulty deltas beyond a shallow reorg.  It doesn't require that the client track any new data sources and it doesn't require an AI to interpret trends.  It also allows a recipient to calculate a waiting time (depth really) for an incoming transaction that provides them with whatever level of concrete mathematical security they desire.

How it would work if you missed all of my posts on this last summer and fall:

First, we want to be able to handle ordinary "honest" reorgs exactly like we've been doing it.  The usual estimate I use for this is once every 300 blocks on average for a single block shuffle.  The reorglog on block explorer says there have been 29 reorgs in the 23523 blocks, or about 1 in 800.  In practice, blockexplorer will be on the winning side about half the time (and thus not record a reorg), so the real number is 1 in 400, which means that my 1 in 300 estimate is fairly close, and is on the conservative side.

That means that on average, we will get a single block reorg every other day.  And a two block reorg every other year.  And a three block reorg twice per millennium.  Beyond that, it gets silly, because there probably won't be an honest six block reorg before the sun burns out.

So, we pick a parameter, call it S, and set it to a number higher than we ever expect to see from an ordinary reorg.  6 would probably be good here, but just to be really safe, I'll go with 12 in my example.

Now, any reorg of depth <= S is handled normally.  The fun happens when an attacker wants to replace more than S blocks in a single shot.

I'm going to call the second parameter P, and it is the base of the exponential function.  Any number greater than 1 will work here.  Bigger numbers work more quickly, but small numbers still work great.  For this example, I'm going to go with 1.05.

Now, we do some calculating.  We go back in our chain to the last common ancestor, the point where the potential new chain split off.  We add up all of the difficulty stored in the blocks after this point, and we call it X, while we are doing that, we count how many of our blocks will need to be thrown out if the reorg succeeds, and we call that D.  Then we add up all of the difficulty beyond this point in the new chain, and we call it Y.  Finally, we calculate F=P^(D-S).

With me so far?  We have:

D - depth of the reorg from our point of view, the number of blocks that will be invalidated
X - difficulty of the reorg, again from our point of view, the amount of work that will be discarded
Y - difficulty of the new chain, the amount of work that will replace X
S - the number of blocks we are discarding
F - The exponential difficulty function that starts small, but grows more or less rapidly

Again, if D <= S, then the comparison is just is Y>X?  If yes, then reorg, if no, then no reorg.  This is simply the current logic.
However, if D > S, then the comparison is Y>(X*F).

If we assume blocks of constant difficulty, P=1.05 and S=12, we get:

12 blocks requires 12 * 1.00 blocks = 12.00 = 13 blocks (the new chain must be longer)
13 blocks requires 13 * 1.05 blocks = 13.65 = 14 blocks
14 blocks requires 14 * 1.10 blocks = 15.43 = 16 blocks
15 blocks requires 15 * 1.15 blocks = 17.36 = 18 blocks
21 blocks requires 21 * 1.55 blocks = 32.57 = 33 blocks (the chain is 50% stronger after just 3.5 hours)
24 blocks requires 24 * 1.79 blocks = 43.10 = 44 blocks
27 blocks requires 27 * 2.08 blocks = 56.13 = 57 blocks (twice as strong after 4.5 hours)
36 blocks requires 36 * 3.22 blocks = 116.10 = 117 blocks
60 blocks requires 60 * 10.4 blocks = 624.07 = 625 blocks (ten times the work needed after 10 hours)
144 blocks requires 144 * 626 blocks = 90229 blocks (after a day, the attacker needs to do over 600 times as much work)

The typical objections to my scheme involve honest network partitions.  I don't see that as a problem.  The worst case would be the network split exactly in half (by hashing power, not node count or geography), and staying divided for about 4 hours (assuming S=12), which is something we would notice, since it would involve aliens blowing up all of our communication satellites and putting the earth on a gigantic bandsaw to cut it into halves along a great circle through Minnesota and Texas.

The U in UTC is "Universal".

I'm going to try to coin a new term here.  the_joint uncertainty principle: If no time zone is specified, the real time indicated by any given representation cannot be known with more than +/- 12 hours accuracy.

The purpose of a central bank is to make bank runs effectively impossible.

Bank runs were a way to keep banks honest.  If any day arrived when they were asked to redeem more deposits than they actually had available, the bank would fail.  The threat of that should be enough to prevent it from ever being necessary, but in practice not so much.  Since restraint seemed to be impossible they cooked up a scheme where all money was virtual, so that a central bank (owned by the other banks) could literally create money out of thin air in any quantity needed to prevent a bank run.  People think that FDIC does this job, but it doesn't.  FDIC is a fig leaf to hide other banking sins.

They got the politicians on board by giving them the power to spend whatever they wanted by automatically creating loans in any quantity the politicians desired.

Fractional reserve is possible in the bitcoin world, but a central bank capable of conjuring coins is not.  Deposit insurance may be possible, but probably would not be practical.  Banking in bitcoin will probably always be very nearly 100% depositor risk, which means that a bank offering high interest to depositors will automatically be highly suspect.  And since the bankers will not be able to offer unlimited spending to the politicians to buy laws favorable to them, fractional reserve will very likely be seen as outright fraud.

Worse.  The weather, last I checked, doesn't actively try to defy the forecasts.

Surprisingly, fourier works perfectly fine on non-periodic signals, sorta.  You can decompose any signal into periodic components, but in lots of cases those components aren't very meaningful.  A random signal will decompose into random components, a DC signal will compose into odd harmonics, etc.

Hmm.  If only someone 200 years ago had devised a method for analyzing signals in terms of simpler signals...

Honestly, financial signals don't really work well under spectral analysis.  The feedback mechanism is too noisy.