Import worked perfect with a different format.
Now I'm noticing that the calculated fee is not populating the fee box even though there is a .001 per input specified in the client settings.
I priorities my new vanity key, manually entered in a fee, hit send, and now I'm getting 'global name 'prioritized_addresses' is not defined'.
sorry about that. I did not take enough time to test things.. edit: here is another bugfix, version 0.54c |
|
|
|
One thing I did notice is that beginning of the private key didn't start with a 5 which I'm kinda use to seeing. I left a little bit of the private key in the example above. Dunno if that has anything to do with the problem.
indeed, that's probably a compressed key format. |
|
|
|
Trying .54...
I imported a vanity key and it does not show up in the receive list. I'd like to set this as a priority address but can't since it's not there.
I found the problem you probably used the new compressed private key format. the client did not import it because these keys are not yet supported. I released 0.54b. it displays an error message instead of making you believe that it imported the key. |
|
|
|
Is there a "freeze" and a "prioritize" command (for the console)?
Is it possible to prioritize a change address?
not now 2 BTC on the way ...  thanks. |
|
|
|
does it show up in text mode?
Not at all. can you check if the imported address is in your wallet file? |
|
|
|
what happens if an addr. is simultaneously frozen and prioritized?
it is frozen |
|
|
|
I imported a vanity key and it does not show up in the receive list. I'd like to set this as a priority address but can't since it's not there.
does it show up in text mode? edit: this makes me think that imported addresses should have a coor too What exactly does a frozen address do (or not do)?
coins received at a frozen addresses will not be used in your transactions. Also, I can't remember if I asked for this or not, but would it be possible to sort the lists by clicking on column headers?
yes you did ask already. |
|
|
|
|
I just released a new version: 0.54
This version introduces several new features in the Qt GUI, that give the user more control on their wallet.
However, these features make the user interface a bit more complicated; I believe I will make them optional in the future, in order to hide this complexity.
List of new features:
* The list of 'change' addresses is visible in a 'change' tab (no interactivity for now)
* The 'receive' tab now has a 'new' button, that allows the user to create addresses beyond the wallet's gap limit. The user gets a warning, and addresses that are beyond the gap limit are displayed in red. The red color will remain until the gap has been filled. (in other words, to fill the gap you need to send coins to the last non-red address of your list).
* Frozen addresses are displayed with a blue background.
* Addresses have a 'priority' flag. Prioritized addresses will be used first when creating a transaction. Prioritized addresses are displayed with a green background.
I know that colored backgrounds are not satisfactory for color blind people; I guess I will add icons in the future.
|
|
|
|
be sure to check out ogrr.com
I've seen that forum-style on other sites, though I did not know of this one, thanks for pointing it out. I think forums like these were, and are, fantastic ideas and definitely a step in the right direction. However, I don't think it's a far enough step - there are dozens of ways to provide this service more efficient and effective than as a forum, and that's where I think this project will thrive. I mean, you should talk to them |
|
|
|
I just asked on the dev channel, and I got confirmation of what I feared: <ThomasV> does ResendWalletTransactions() check tx inputs?
<sipa> ThomasV: how do you mean?
<sipa> ThomasV: it just resends all unconfirmed transactions
<ThomasV> sipa: double spends, etc
<ThomasV> sipa: https://bitcointalk.org/index.php?topic=85689.msg944505#msg944505
<sipa> ThomasV: the current wallet code basically always assumes that its transactions are valid and will eventually confirm
<sipa> that's a major flaw
<ThomasV> sipa: what if a tx has become a double spent because of a reorg?
<ThomasV> could this explain the error reported there?
<sipa> ThomasV: i suppose
<ThomasV> sipa: what should this user do?
<ThomasV> (you might get a bounty if you answer in the thread)
so, this might explain your problem, even if it does not really solve it. I guess you could try to remove the transactions from your wallet using pywallet. make sure you back it up before. |
|
|
|
I used my current wallet with a backup of all the rest of the files in the bitcoin folder from 1 day prior to the unconfirmed transactions. My understanding was that the wallet contained nothing but the private keys. Is this incorrect?
No, I believe the wallet.dat also contains transactions stored. If you use the same it won't work. the debug file suggests that these stored transactions are resent without being checked. they might have become double-spents because of a reorg. I guess it would make sense for ResendWalletTransactions() to check old transactions inputs again. Does it redo this check? |
|
|
|
signmessage / verifymessage don't seem to work for me, verify always produces False - could someone else test as well?
I am aware of the issue; there are two problems: - a module was mising in setup.py this is fixed in git (see recent commits) - verifymessage fails with compressed keys (the new format used by the satoshi client). the result is that it will return False on a string signed by the satoshi client using a recent wallet. this was reported by nanotube. it is not fixed yet. |
|
|
|
Note:
I searched for the 5 transactions you reported in the debug.log of my Electrum server (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.
why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?
These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance. sorry for the confusion :-) it looks like they were rejected by the network. check your own debug.log to see the cause (probably a blockchain reorg). What should I search for? search for ERROR. on Linux, you can use grep : cat debug.log | grep -10 ERROR you should see lines that look like this: ERROR: ConnectInputs() : 6501716a6a mapTransactions prev not found 3ad23a50d9 (with different numbers) you can also use the first chars of the transaction hashes in the grep command: cat debug.log | grep -10 ccf585 |
|
|
|
Note:
I searched for the 5 transactions you reported in the debug.log of my Electrum server (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.
why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?
These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance. sorry for the confusion :-) it looks like they were rejected by the network. check your own debug.log to see the cause (probably a blockchain reorg). |
|
|
|
|
Note:
I searched for the 5 transactions you reported in the debug.log of my Electrum server (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.
why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?
|
|
|
|
I have 84 other send transactions that confirmed as normal during the same time period.
this suggests that your client is OK. if you reload the blockchain from scratch it will interrupt your service, and you'll get more angry customers. just stop your bitcoind and restart it, and check if these transactions are still displayed by your client; they might have been rejected by the network (eg double spend) |
|
|
|
|
be sure to check out ogrr.com
|
|
|
|
EDIT2: I have fixed this in Windows build 0.53-2 (just released) - There were some HTTP-related
libs missing following the upgrade to Python 2.7.3.1.
Was this a problem on the client? From what I see in the traffic, the client is polling the server just fine - it's just not getting back the transaction notification. I confirm that there is a problem with notifications and http. I am investigating it edit: this was a server bug. I fixed it. it should work now (at least on ecdsa.org) |
|
|
|
this is the only bitcoin related site that i have used this password on.
what does "this" refer to? mtgox or glbse? |
|
|
|
anyone have any idea what i can do now?
any idea how the attack was possible? did you use a strong password? yubikey? |
|
|
|
|
Show Posts
