Impressive how people are so concerned about "backing" money with something... you're missing the point. And by the way, nothing has inherent value. The point of backing the bitcoin with proofs is that it is a digital "product" and thus totally anonymous. As of now, I would not use bitcoins because I can't exchange them for anything of value without risking breaking the law. However a completely digital exchange can be done with much better security. Unfortunately, proofs don't have much of a market right now. what law would you be breaking by buying something with bitcoins as they are now? (and while you are at it, let us know what country you are in).
|
|
|
ah, theymos, you're here - so what about the key pool? will the 'looking at wallet backup' thing work?
Yes. It's good for 100 generations (and you can use the -keypool switch to increase this). I think an auto-send script would be easier, though. Also, I think there may be some cases where a keypool address would be thrown away without a generation (like if Bitcoin crashes, or maybe even when it shuts down). well, if he's generating on a CPU rather than GPU, 100 addresses for several months should be way more than enough. that said, indeed autosend script should be pretty easy to write as well. check balance, if >0, send balance to $myaddress. crontab it, and you're done.
|
|
|
well, if you're savvy with pgp or truecrypt, you could do your encryption yourself. that said, i don't think it's a bad idea to have the option to store the wallet as an encrypted file which requires a passphrase upon every bitcoin start, etc. that way the file is 'encrypted by default', which is not a bad place to be.
|
|
|
Should any Bitcoin be generated for it, will the address that the Bitcoin is sent to be the address that was initially generated for the client?
No. Each generation has a unique address created for it. This address is not shown in any Bitcoin interface. You could make a script that sends all generated coins to some address, such as this one: http://bitcointalk.org/index.php?topic=1431.0ah, theymos, you're here - so what about the key pool? will the 'looking at wallet backup' thing work?
|
|
|
I plan to run the Bitcoin client on an underutilized server at an off-site location. I cannot remote into it and won't be back to that location for at least a couple of months from now. Thus I won't know if it generated any Bitcoin, nor would I be able to transfer it before my next visit. Should any Bitcoin be generated for it, will the address that the Bitcoin is sent to be the address that was initially generated for the client? If so, then as long as I record that address, I can then periodically check the status here: http://theymos.ath.cx:64150/bbe/address/xxxxxxx [xxxx = address] Additionally, if I created a backup of the wallet and have it with me, I should be able to fire up another client here, restore the wallet and be able to transfer the Bitcoin away, correct? no, each block generation bounty gets credited to a new address, so monitoring the 'first address' will not be of use. the bitcoin client now pre-generates a 'pool' of keys, sized 100 by default. i /think/ (but am not sure) that the addresses used for generation are also taken from this pool. if that is the case, then if you make a backup of the wallet and look at it on your local machine periodically, you'll be able to see the generation credits in your wallet backup (at least until you run out of the 100 pool addresses - depending on how fast your remote machine is generating, it may happen very fast or quite slowly). but since i'm not sure if the pool addresses are used for generation, you should get confirmation on that from someone who knows what's up.
|
|
|
morpheus: just fyi, there is some mtgusd-usd trading activity going on on #bitcoin-otc. might want to post your offer there as well. </plug>
|
|
|
Even the price and volume of this small accuracy generates such large precision numbers when you using "limit" orders type.
Still, as i said, no problem for me. It doesn't cost my eyes anything to see extra digits. Do not want to seem intrusive, but we have no such restriction. More precisely, now you can write approx 15 characters of price.
checked out your exchange site... a few comments for you, which i hope may be helpful. more competition in exchanges is always good. 1. it seems that there are no outstanding asks on the site? you need to get some market makers in there, at least until you have a bigger population of traders. 2. your fees seem to be rather large... 6% one way, 50rub the other way? if you want to compete with established exchanges like bcm and mtgox, you have to offer competitive fees. or possibly even start with zero fees, to attract clientele 3. don't know how possible it is... but if you allowed USD exchange on your site as well as RUB, you'd have more interested clientele. 3.1. To that end, you need to finish your translation to EN, there's a bunch of russian in places even if EN is selected. The 'rules' page is in fact completely in russian. Well, that's it for now. hope that helps.
|
|
|
The clients simply display the values with a decimal point in the middle of the base 10 translation of the integer, as there are 8 decimal places to each side of the display. Changing that might prove to be a breaking change, and may not be an easy one.
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately. Yes that has been my understanding as well... though I certainly haven't actually looked at any code to confirm.
|
|
|
+1 on showing actual balances without rounding.
are you ready to see the numbers like this: 12.3234453404553525454656 ? Why, yes, yes i am. Bring them on, please. As long as they accurately represent the balance in my account, it's all good. Though note that it should never get to so many decimal places, since there's a limit to how many decimal places bid/ask offer inputs can take. But even if it does - I'd rather see the real amount than a rounded one.
|
|
|
IMHO, this is a very special paranoid. Javascript no less shit than the flash. But the flash, at least in theory, can run in a sandbox.
so can javascript - if you run the whole browser in a sandbox which is the only type of sandbox i'd trust with flash, too heh. but anyway - i completely agree, both js and flash are annoying, and i'd be very happy to see a nice static-html trading site. you can have a 'special' js or flash live-ticker, or live order book display, or live-updating chart... but besides that, a person should have complete functionality without flash or js. in my book, if it's not automatic-live-updating... there's no call for requiring flash or js. problem with mtg is it uses javascript... but the order book and charts are not live-updating (as in, page has to be refreshed, or button manually clicked, to refresh the view). so it's like the worst of both worlds on this issue. but it is a very nice and functional site in other respects, and has a relatively deep market.
|
|
|
I suggest to remove all mandatory rounding. If i want to send 1.02345 btc, I should damn well be able to. (Well, I still can, with a modified client... but I shouldn't need to modify the client.) The 'max 8 decimal places' can stay for a while... but the forced rounding should go. Now, the client may still trim trailing zeros to neaten display, that would be fine, but forced rounding has got to go. As far as "moving decimal point"... I think maybe instead the client should just acquire a dropdown box next to the balance display and other amount displays, where you get to choose the units (bitcoins, bitcents, microcoins, etc). As bitcoin value goes up, the "default" unit may change, but full-coin-unit display should always be possible. Just my 0.0298723 BTC
|
|
|
+1 on showing actual balances without rounding.
+1 on pre-calculating the fee that would be charged, and showing it to the user to see before submitting an order.
|
|
|
OK cool, didn't know that. Must be pretty new, when I checked last time they didn't support it yet.
well, it's /relatively/ new, but it's been more than a year at least.
|
|
|
I recommend, instead of the GPL licence, maybe consider using the Apache License, Version 2.0.
and fwiw, i recommend gplv3
|
|
|
just a suggestion: before you resort to doing 'custom software' consider using existing software for data shaping/analysis, such as R, for example (and it's foss, to boot!) teaching people to use an existing data analysis sw is probably more useful than teaching them how to use your custom software.
|
|
|
oh... too bad. well, i wish you productivity in your other endeavors.
|
|
|
|