Thanks, I want something that I can run totally offline, readme says: * Relies on centralized service (blockchain.info) for blockchain operations, although operations do have backups (eligius, blockr.io) It can be run offline. Just that if you want to do anything involving the network (e.g. send transactions), then you need to be connected to the internet (duh). Also, not sure if I see the command to take one or both binary or decimal to WIF, I do see these instructions:
### Listing of main commands:
* privkey_to_pubkey : (privkey) -> pubkey
* privtopub : (privkey) -> pubkey
* pubkey_to_address : (pubkey) -> address
* pubtoaddr : (pubkey) -> address
* privkey_to_address : (privkey) -> address
* privtoaddr : (privkey) -> address
but nothing for private key in binary or decimal to WIF.
There has to be a simple code to do this somewhere. (yeah, I know its not that simple)
It does, the commands are encode_privkey and decode_privkey. Look at https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/main.py#L222 for some reference. |
|
|
|
No, only 0.12+ because the sendHeaders message does not exist prior to 0.12.
It should fallback to inv messages in that case. Is there a reason for not doing that? Not sure. That is just what I understood from the release notes and the bip. I suppose a more definitive answer could be gotten by looking at the code. |
|
|
|
|
The easiest solution is to reindex everything. I think that would work. However, before you do that, check the permissions of everything in the data directory. Make sure that the you are able to have read and write access to everything since that error seems like you have a permissions problem.
It would also be helpful if you gave us the full Debug log.
|
|
|
|
|
There are no reliable node counts because nodes can be spoofed and not every node owner will want to be connected to the node counting service. I know of several people who have said that they refuse connections to bitnodes.
|
|
|
|
|
That would be a miner's address. Bitcoin miners get a mining reward of 25BTC plus some extra from the transaction fees.
Do some research on bitcoin and how it works behind the scenes, there is info about it everywhere on the internet.
|
|
|
|
|
This is something that is fairly easy to implement. It could all happen on chain and that would be the easiest to implement. No changes would need to be made to Bitcoin at all, all of the stuff is already there. A simple solution would be to use NFC to send the buyer a Payment Request or a link to a Payment Request. Then the user just confirms the send and types in his password and the app sends the Bitcoin to the right place. All of the details that the app needs to know is contained within the Payment Request.
|
|
|
|
So when we expect this 0.12.0 release to be officially available?
Meanwhile classic gained ground, now they are 14% (830 nodes) of the total number of nodes.
Soon I think. Rc5 was tagged today and during the meeting today it was mentioned that rc5 would be the last rc for 0.12 |
|
|
|
|
Check your firewalls that they allow port 8333 both in and outbound connections.
|
|
|
|
It probably had to do with the wallet you were using. Did you happen to send any bitcoin after you sent this transaction? If so, it if possible that your wallet allowed you to accidentally create a double spend.
and how this happen exactly? it look like a bug, and nt a thing done on purpose, if this is the case, it's a bit dangerous, since it can happen with larger amount Usually a bug, I have seen blockchain.info do something like this before. |
|
|
|
|
It should be safe since most Android wallets are decently secure. Just make sure you have backups in case your phone is damaged, stolen, or lost. I recommend that you use Mycelium as your wallet.
|
|
|
|
|
It probably had to do with the wallet you were using. Did you happen to send any bitcoin after you sent this transaction? If so, it if possible that your wallet allowed you to accidentally create a double spend.
|
|
|
|
Additionally, the input address isn't actually gotten from any public key in the input. Rather that address is retrieved by checking the specified output since there are special p2sh addresses that exist that don't even use public keys anywhere in them.
It is possible to determine the addresses based on the pubkeys or redeem scripts when those appear in input scripts, without having to check the transaction that is being spent. Maybe I'm using the wrong terminology here, but I can show you an example if you want. I know that, but when properly validating a transaction, in some cases such as this one, there is no need to have the input scripts have the necessary data to derive the address. Properly validating a transaction means that the node will still need to fetch the necessary output script in order to determine that the input script properly spends the output. Modern transactions use the hash160, and in order to get the hash160 properly, the public key (the digest)is required so that it can be used to check the signature (since the hash160 can't provide the public key to do that) and then checked against the hash160 to ensure that it is the proper public key. However, in this case, the pubkey is already supplied by the output script, so it is not necessary to include the public key in the input script since the input script will validate directly against the public key provided by the output. |
|
|
|
|
This transaction spends from a transaction that used the old format for spending. The old format was pay-to-pubkey so the public key was already stated in the output the input references. Since the input references an output and that output has the necessary information to determine an address, it is not necessary to have the public key anywhere, all you need to do is look at the referenced output to get the input address. Additionally, the input address isn't actually gotten from any public key in the input. Rather that address is retrieved by checking the specified output since there are special p2sh addresses that exist that don't even use public keys anywhere in them.
|
|
|
|
|
Interesting idea. I'm trying to find the private key, but so far, no luck. Any hints?
|
|
|
|
Thanks knightdk. I am trying that and its in the middle of downloading as I write this.
I have another question... if I click off "let armory run bitcoind in the background" and run Bitcoin Core myself, does that also need to finish its download / sync with the network before I am able to see my transaction?
Thanks.
Yes, the only difference is that you will need to start bitcoin core yourself when you start armory otherwise it won't work. Armory relies on bitcoin core, it doesn't matter how it is started, the stuff it uses and needs are still the same. |
|
|
|
When you say that it was on a fully synced node previously, does it matter what the block height was, or, like you said, the wallet should be consistent as long as it was shut down properly?
The block height might matter. I think there is a field in the wallet.dat file that stores the best chain and that does matter because it would indicate the last block the start scanning from. On a full node, that doesn't really matter since all of the data is there, but on a pruned node, that latest block might not be in the databases so it would be unable to scan for new transactions. If you pulled the wallet file from a fully synced node and transferred it to the pruned node immediately, it should work right away. |
|
|
|
I've been testing out 0.12.0rc3 in pruned mode, and have run into the following error message when restarting Bitcoin Core: "last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node)" To reproduce: 0.) Start from scratch, deleting the entire Bitcoin data directory if it exists (leaving no wallet file or blockchain data). 1.) Install Bitcoin Core 2.) Create Bitcoin data directory if it doesn't exist, create bitcoin.conf, set "prune=550" without quotes 3.) Run Bitcoin Core 4.) After you've verified, say, 100,000 blocks, close Bitcoin Core. Wait until the warning window to not shutdown/restart computer completely closes. 5.) Run Bitcoin Core again, let it verify some more, close it again. 6.) Rinse and repeat step 5... At some point, I get the above error message on starting Bitcoin Core. I don't know what exactly is causing this, but if you're like me and you've verified a large amount of blocks and then you're told that you have to start completely over, you'll probably be pissed. This error message is not new, as a related fix for this kind of error, when converting non-pruned nodes to pruned nodes was made here: https://github.com/bitcoin/bitcoin/issues/6345While it's obviously easy to reproduce this error *if* you try plopping an *already existing* wallet.dat file into a pruned node data directory and then running Core -- that's not what I've been experiencing. I've been seeing this error with a brand new wallet.dat that was created from scratch *alongside* a fresh, pruned node. Edit: If it's a brand new node from scratch, it seems that if you delete the wallet.dat after getting this error, a brand new one will be created, and the blockchain will continue to sync from where it left off, so at least there's that, though, it's still a bug. Not sure what would cause this, but you would get a better response by posting on the github issue tracker. Or rather watch the issue thread that gmaxwell opened for you here: https://github.com/bitcoin/bitcoin/issues/7494 |
|
|
|
|
Show Posts
