<?
$a=file_get_contents("http://mtgox.com/code/data/ticker.php");
$res=(json_decode($a, true));
$low = $res['ticker']['low'];
$a=file_get_contents("http://bitcoincharts.com/t/weighted_prices.json");
$res=(json_decode($a, true));
$day = $res['USD']['24h'];
echo min($low, $day);
?> file_get_contents might not work with https http://mtgox.com/code/data/ticker.php is *really* long to respond, too |
|
|
|
Nope, you should test with the curl function then |
|
|
|
|
Next release will include wallet encryption
But I don't believe it will include custom filenames
|
|
|
|
|
While dealing with php files, you always need to put the code between '<?' and '?>'
|
|
|
|
recent allinvain theft
Wat? |
|
|
|
$a=ouvrirpage("https://mtgox.com/code/data/ticker.php");
$res=(json_decode($a, true));
$low = $res['ticker']['low'];
$a=ouvrirpage("http://bitcoincharts.com/t/weighted_prices.json");
$res=(json_decode($a, true));
$day = $res['USD']['24h'];
echo min($low, $day);
function ouvrirpage($site){
$ch = curl_init($site);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$res = curl_exec($ch);
curl_close($ch);
return $res;
}or if you don't like curl: $a=file_get_contents("https://mtgox.com/code/data/ticker.php");
$res=(json_decode($a, true));
$low = $res['ticker']['low'];
$a=file_get_contents("http://bitcoincharts.com/t/weighted_prices.json");
$res=(json_decode($a, true));
$day = $res['USD']['24h'];
echo min($low, $day);
|
|
|
|
- Bugfix for private key encoder. It was possible for it to output a shorter-than-expected private key. If you have a private key that does not start with a 5, or is less than 51 characters long, don't use it. If you have such a private key with a bitcoin balance, contact me for assistance.
Maybe you should analyse the base58 key, and print the hex private key if the base58 key is not valid |
|
|
|
Yeah, because I have yet to find a way to convert it from base58 into a usable hex key like the ones stored in the wallet... At least to know what the result of such a conversion looks like, would already be a big help. EDIT: Hexprivkey: a7593394a809fe36b10fb3203480dd789fd12e771b07e3df50b37080714f1d2e oh cool! are these two 6398247687543120230611217925528537819731860764507939242623555882076675375130382 and a7593394a809fe36b10fb3203480dd789fd12e771b07e3df50b37080714f1d2e the same? I'm sure a7593394a809fe36b10fb3203480dd789fd12e771b07e3df50b37080714f1d2e is equivalent to 5K5zGnFRJAD3viw93hPQLq5Fa3xsLFGYC9yoGMcmVdS1CEaKYs7 If you are sure 5K5zGnFRJAD3viw93hPQLq5Fa3xsLFGYC9yoGMcmVdS1CEaKYs7 is equivalent to 6398247687543120230611217925528537819731860764507939242623555882076675375130382 Then yes they are the same Allow me to inject some sanity into this adventure (although it is fun):
(1) An ECDSA private key is literally a random number, between 1 and slightly less than 2^256 (something like 0.999999999*(2^256))
(2) Any number greater than that range is identical to private key that is in in the range of (1)
Therefore, you can pick yourself a 4000-bit ECDSA key if you wanted, but there's an equivalent 256-bit key, and you might as well use that one because it's shorter.
Speaking of this, I miscalculated in my previous post. The maximum address size is actually 33 Base58 characters, so I shouldn't have given you a hard time about wanting to calculate 58^33. Sorry!
-Eto
For those interested by the exact value: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 is equivalent to 0, so [...]142 to 1, etc |
|
|
|
there is one positive aspect regarding the sudden price drop... people might actually spend them buying services rather than hording them.
people held on to them like no tomorrow because they though the price would go up... now it's proven that isn't the case... so they might be more inclined to spend them.... if merchants want to accept that risk now.
Or they sell all their coins quickly... Which makes the price even lower |
|
|
|
Pywallet says: Address (Bitcoin): 1GPtKcQXVnayMz7fjyZnr89oVoFiCMTv2P
Privkey (Bitcoin): 5K5zGnFRJAD3viw93hPQLq5Fa3xsLFGYC9yoGMcmVdS1CEaKYs7
Hexprivkey: a7593394a809fe36b10fb3203480dd789fd12e771b07e3df50b37080714f1d2e And Block Explorer says 'never used'  |
|
|
|
Btw, why do you need 58**33? For bitcoin, most Base58 addresses are about 25 characters long. This means, the biggest int you would need would be about 58**26
What do you mean? My favorite priv key, 5K5zGnFRJAD3viw93hPQLq5Fa3xsLFGYC9yoGMcmVdS1CEaKYs7, which I use everywhere, is 50 characters long! (more or less) . I bet it's a fake  |
|
|
|
You can use any 256bit number as private key, except 0
This is true. However, there are a fixed number of points on each elliptic curve, and for the secp256k1 curve used by bitcoin, there are fewer than 2^256: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 This value is equivalent to 0 and isn't valid. However, one plus this value is equivalent to 1. Don't use anything equal or larger than this value as a private key. Thanks for this info! I'll add a warning in pywallet |
|
|
|
Are wallet a and b completely different? I mean can a wallet now be never online and still do transactions?
Yes absolutely But the offline wallet still needs to have a blockchain where it sees it can spends the amount of the tx This doesn't need to be online, transfering the blk* files with a USB drive is enough |
|
|
|
Un serveur VNC sera également mis en place sur mon ordinateur, afin que ceux qui le veulent puissent suivre en direct l'intervention.
Enorme, j'adore! Pour faire plus constructif, c'est bien que ça bouge, vivement qu'il y ait plus de monde sur la pool J'espère que tout se passera bien... |
|
|
|
This is great.
The tx_k and tx_v values, does anyone know how they are generated ?
I guess they are signed with the private key.
They are the data that the client wrote inside the wallet, so yes it must be signed I'm not sure I'd call this EASY, but it certainly is workable. Not to mention it makes a starting point for actually making it easy.
Updated, one can now export tx's to a file and import the file, see 'short method' I can't make it easier |
|
|
|
|
Strange...
Kill and run it again, it must be enough
|
|
|
|
|
You killed bitcoind, run it again
I mean the first bitcoind, the one without arguments
|
|
|
|
Instead you can create yourself your privkey (at least the hex one, 64 characters long, I don't know if all base59 ones are valid they are not because of the checksum) using your own pattern that you know by heart, thus no need to write it
E.g. 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef for 19ffB4HttNCHfY1t3YuErEytCspyHyVMwv
Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey? importprivkey says it's not. #> bitcoin importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
error: {"code":-5,"message":"Invalid private key"}
Afaik, importprivkey only accepts base58 privkeys I didn't think you could just use any 256 bit number as private key. Please, someone knowledgable clear this up for me.
You can use any 256bit number as private key, except 0 |
|
|
|
|
Completely agree with OP
See the current situation of Namecoin...
|
|
|
|
|
Show Posts
