You can easily choose another more flat curve though. I think the chosen one could turn out to be suboptimal if it hinders adoption.
That's true. I suppose the matter of the curve is a struggle to reach a balance between providing an crucial incentive for early adopters and keeping later adopters from being shut out of the market. As far as that goes, I hope that the curve won't discourage use (it certainly hasn't discouraged me), but I guess only time will tell. Perhaps the fact that it is possible to trace the transaction history back will cause the disgruntled to value recently mined Bitcoins more than older ones... |
|
|
|
|
As someone without a graphics card new enough to mine with or enough spare money to buy one, it can seem a little unfair. However, when I think about it, I can't think of any better way to distribute Bitcoin around that wouldn't be vulnerable to attack. Two thousand years ago, I could have complained that gold was unfairly distributed, but in the end, gold was secure and useful and that's what mattered. I use Bitcoins because they're secure and useful.
|
|
|
|
Awesome, that worked thanks  @Unfinishe: Just sent you a coin using my new binary, plus an extra 1 for matt Thank you so much!  |
|
|
|
maybe I'm missing something but are there some errors in these numbers for BTC days destroyed? Some blocks have negative values for days destroyed. For example see block 65711 has -151.03 BTC days destroyed. There are 48 other blocks in this csv file with negative numbers for days destroyed. Very interesting data and analysis by the way. thanks to all concerned. Well, looking at the Block Explorer for block 65711, it seems that the previous block 65710, which holds the redeemed output, actually has a timestamp that is later than block 65711. So, apparently the calculation is "correct", but I honestly don't know why the dates are backwards... |
|
|
|
I went through all the steps and finally when I did make -f makefile.mingw I got this: In file included from util.cpp:5:0:
headers.h:62:29: fatal error: boost/foreach.hpp: No such file or directory
compilation terminated.
make: *** [obj/util.o] Error 1
I tried copying the boost folder to the bitcoin src directory but got the same error... I don't know where I need to move it to in order for it to be found. The makefile is looking for the boost folder at C:\boost-1.43.0-mgw . It's possible that there is a typo or something. |
|
|
|
Well, I have managed to compile the latest source on Windows XP SP3 with ssl support just fine by editing makefile.mingw: line 28: to -l db_cxx \
-l ssl \
-l eay32 and line 33: DEFS=-DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH to DEFS=-DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -DUSE_SSL and then following the instructions here: http://forum.bitcoin.org/index.php?topic=5851. |
|
|
|
I confused myself pretty quickly trying to figure out what's going on, so I don't know whether this has anything to do with the problem. Earlier I was trying to replicate the original hash by using openssl on the command line. I first digested the data using sha512, then signed with the private key, and then encoded into base64, but the signature didn't match. So I looked around and found this thread: http://www.ruby-forum.com/topic/77070It seems that the sign function in ruby does something different than doing it step by step with openssl like I was trying to. Instead, the private_encrypt function seems to do the trick. Perhaps something like this would work better private_key = OpenSSL::PKey::RSA.new(privkey)
data_digest = OpenSSL::Digest::SHA512.hexdigest(data)
b64sig=Base64.encode64(private_key.private_encrypt(data_digest))
|
|
|
|
|
I very much like pie, but I had to vote that it is a good idea. It's a common enough trade and there's nothing wrong with more organization.
|
|
|
|
|
I think I've got an idea on how to do this, but I'm rusty on my python, so please bear with me for a little while...
|
|
|
|
Well, I'm going to declare unfinishe the winner (...it needs cryptographic keys). I'll be finishing the shirt and posting it and the store announcement sometime next week. Infinishe, you want me to send the funds to the address in your signature line?
Sure, that works just fine. Thank you very much! |
|
|
|
|
Payment is confirmed. Thank you!
|
|
|
|
I think that the main problem is that Bitcoins seem risky, especially to the technologically impaired, and men are more likely to both take risks and be interested in technology. Until the Bitcoin market becomes more stable and accessible, I'm afraid that we're gonna be stuck in a sausage fest. |
|
|
|
|
The problem is that none of us probably have enough influence to get a unique name like 'Gav' to really catch on (unless it was especially catchy), so it would have to be immediately intuitive to anyone who saw it that you mean 0.001 Bitcoins. Using milli- is the most obvious, but milliBitcoins doesn't exactly roll off the tongue. I would recommend shortening it to something like "mCoins", and then abbreviate as mBTC until perhaps mC catches on. But, that's just my two Bitcents. Someone will probably have a better idea and we'll end up using that instead.
|
|
|
|
unfinishe, I accidently sent you two payments. If you want to send one back to 1DcuJLebJg6QJWAQbVEqGWZVuBpTAkXf94, cool, if not, I won't hate you for it. It was my mistake.
Somebody sent me 0.25 BTC by mistake? Haha, sucker! (Just kidding.  Sent) |
|
|
|
|
I don't want to undercut lulzplzkthx, but in case it doesn't work out, I'm interested as well.
|
|
|
|
Ok, so upon further research (I'm sorry for not doing a more initially), it seems that your best bet is to write a raw SQL query. http://docs.djangoproject.com/en/1.2/topics/db/sql/#performing-raw-sql-queriesI can't write the exact code and query without knowing more details about the database you're using, the tables and such, but assuming you're using PostGIS, it should go something like this: Orders.objects.raw('SELECT * FROM orders WHERE ST_Distance( point, %s ) < maxdistance', [original_point]);Fiddle around with it and let me know if it works. |
|
|
|
|
Show Posts
)
