There are several ways to serialize EC public keys, as specified by the SEC specification. A summary: * 0x00: The point at infinity * 0x02 + x_coord: Compressed representation of a point with an even y_coord * 0x03 + x_coord: Compressed representation of a point with an odd y_coord * 0x04 + x_coord + y_coord: Uncompressed representation of a point Up to 0.5.x, bitcoin always used uncompressed EC points (=public keys). Starting with 0.6.0, compressed public keys will be used for new or upgraded wallets. |
|
|
|
+1 for an implementation in a safer language.
I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.
We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.
I hate Java more than Python, than Basic ... Windows is written in what language? Linux kernel is written in? Dia Can you please stop discussing what language Bitcoin clients are supposed to be written in? This thread is about the specific security problem found here. Start a discussion in the dev section, if you like a language flamewar. |
|
|
|
Is this affecting Bitcoin version 0.3.21?
No, only windows version of Bitcoin-Qt are affected, a GUI that was only merged in 0.5.0. However, it's generally a bad idea to keep using such old versions... |
|
|
|
|
There is talk about enabling bitcoin to run as a tor hidden servicie, so it can work without needing an exit node.
|
|
|
|
|
That's a known problem in rc4. A fix was already merged, and will be part of rc5 (which should be ready very soon).
|
|
|
|
Validating creates quite a bit of load on the CPU, so it will most likely be bottlenecked by the CPU. A fast connection should easily be able to download the entire blockchain within 30 minutes, as long as the client is well connected with a working uPnP setup. We'll have to wait and see I guess  Does anyone know how I can check whether this Pull is included in 0.6RC1? I would like to give this a shot, but I'm not capable of compiling Bitcoin myself. Thanks It was only merged today. 0.6.0rc1 is 1.5 month old. 0.6.0rc4 is 6 days old. It will be included in 0.6.0rc5. You shouldn't run outdated release candidates by the way - there's a reason a newer rc was created: the old one had (too many) bugs. |
|
|
|
This is awesome news! A full blockchain download in 33 minutes on a laptop is excellent! Thank you all who made this possible, you've just majorly lowered the bar to entry [/quote] Note that that is not including the downloading, only processing them - I imported it from a local file. I assume in normal circumstances it will still take an hour or two (and if you have bad luck, a lot more) to download. |
|
|
|
That's great news.
Thanks sipa.
I just did some testing for good parameters. Tweaking them was Gavin's idea. |
|
|
|
Of course (can't believe I missed that). So yeah it is more like a million fold (maybe billion fold) easier to verify than produce.
That factor is determined exactly by difficulty*4295032833. That is how much harder it is to find a block nonce at a given difficulty vs. verifying it. |
|
|
|
|
No:
verification: CPU is the bottleneck
indexing: HDD latency is the bottleneck
download: network/p2p is the bottleneck
Indexing almost always outweighed the other two, unless you were running on a ramdrive.
|
|
|
|
|
And today it was merged into mainline, so it will be part of 0.6.0 final.
|
|
|
|
|
By tweaking some caching settings, a rather spectacular speed increase for loading a block chain was obtained. This will probably end up in 0.6 still.
|
|
|
|
Calculating how much was received by addresses that are not your own (i.e. transactions that are not in your wallet) would require either a full blockchain rescan, or an index with the balances of all addresses to be kept. Since this information is not needed in normal operation, such an index is not implemented.
Short answer: currently not possible with the reference client.
so i'm guessing then, merchants who generate a pool of addresses offline using bitaddress.org and then import them into a db to give out to customers (instead of generating addresses on-the-fly), just use the blockexplorer api to check for incoming payments. One other possibility is using a wallet with a large pool of pregenerated keys, encrypting it, and put the encrypted wallet but not the password on the webserver. This way the bitcoind on the webserver can observe incoming (and outgoing) payments, but not spend it by itself. Type-2 determinstic wallets would bring a cleaner solution here. They're not yet supported in bitcoind, but I'm working on it. |
|
|
|
|
Calculating how much was received by addresses that are not your own (i.e. transactions that are not in your wallet) would require either a full blockchain rescan, or an index with the balances of all addresses to be kept. Since this information is not needed in normal operation, such an index is not implemented.
Short answer: currently not possible with the reference client.
|
|
|
|
anybody willing answer few noob translation questions?
I'm halfway done with a new language but would like to check some things first (lang code, special characters in the strings),
edit: at the time of writing the OP I finished 90 % of a new language for the QT and need advice how to enter tags, which tags are allowed, which tags are reserved and how to not translate variable names, what are the local conventions.
come on! I'm not asking for a loan here.
First of all: thank you for the effort of starting a new translation, and sorry that you did not get a reply. I believe updates to a stickied thread are fairly invisible; i didn't notice it until now. I'm not sure what you mean by tags, but considering your question below: the translated string should be as similar to the english one as possible. If the english one had a %s or %n or %d, it means that is going to be replaced by a number or another string, and you should have such a %d/%n as well in the translation. |
|
|
|
now please for the non-coders: are the the posted (above) windows-binaries safe? Yes. |
|
|
|
|
You can also only allow transactions if at least 0.0005 (or even up to 0.01) BTC is present in the user's account, but only subtract the actually used fee?
|
|
|
|
2: if the administrator of my vps, or a hacker hacked in my vps, he got the access of all my files, he saw my source code with the password, then he can steal all my coins with the password right? any other ways to improve the protection of such accidents? (because there are always new vulnerables found, for apache, for linux etc..)
If you're going to run a service which needs to be able to send transactions by itself, my only advice it so only run it on hardware you own, or pay the hosting company for the level of protection you need. At least, for now. When multisig transaction become commonplace, other solutions may be possible. If you're just going to receive transactions, pre-generate 1000 addresses and put them on the webserver, but run no live bitcoind there. 3: how can i know about the translation fee before send bitcoins? ie, if a client has 15btcs in his account, and he send 15btcs out, how can i know how much is the fee of this translation before process it? because it might be free, it might be 0.01btc, it might be 1btc, i need to calculate the amount available before process his request. btw, i don't really get the definition of translation fee, is that obligatory or voluntary? if you pay, your request get faster process by btc network,if not, your request will still be processed, but just slower, right?
That's currently hard: you can set the voluntary fee to 0, but bitcoind will always add a fee if it considers it absolutely necessary (too small outputs, too young/small inputs, too large, ...). This is usually very small, but whether it is necessary can depend on random factors (the input coin selection is random, so the fee requirement may or may not be there, though it rarely has much influence. |
|
|
|
1: in my source code,"$bitcoin = new jsonRPCClient(' http://superman:{super}@127.0.0.1:8332/'" here superman is a username,and super is a password, are they the same as wallet encryption function of Bitcoin-Qt? i mean if someone steal the wallet.dat, but he doesn't know this password, can he send any coins out with the wallet.dat? if this is just an independent password of bitcoind daemon, then how can i set up a password for all out going requests just like wallet encryption function of Bitcoin-Qt? You can access the wallet encryption via the walletpassphrase, walletlock, encryptwallet and walletpassphrasechange commands. The RPC password however is something completely different: it's only for authenticating the RPC call itself. Wallet encryption is independent. |
|
|
|
|
Because addresses do not correspond exactly to wallets: if you do not know how change addresses work, these numbers will give you a wrong impression.
|
|
|
|
|
Show Posts
