Hi, I m retreiving this info when running
bitcoin-cli getinfo
Errors: "Warning this version is obsolete, upgrade required"
The same command reports me back:
version: 90500
Protocol Version: 70002
Wallet Version: 60000
Do I really need to upgrade?. By the way it works like a charm appart from this message and I ve been reading that the core of the client always remains the same. And, how could I upgrade?. I compiled bitcoind and bitcoin-qt by myself and it is not in my repositoires, I m using ubuntu based linux. Really need to remove bitcoind and bitcoin-qt and compile it again to the last version?. It is then, sudo apt-get --purge autoremove packagename my best choice?. Told you so because this command will remove the libraries if I m not wrong.
Yes you really do need to upgrade. This is an important upgrade because of a few soft forks that have happened since your version and some upcoming soft forks as well. Upgrading is really easy when you compile it by yourself, no need to use the package manager. Just download the git source, checkout 0.12.1, build it and install it with make install. That will overwrite the old binaries and install the new version. I ve been reading that the command
bitcoin-cli getinfo
is not available on last version, so, whats the new way to retreive all this VIP data?.
version, protocol version, wallet version, balance, blocks, time offset, connections, proxy, difficulty, testnet, key poololdest, key poolsize, unlocked until, pay tx fee, relay fee, errors.
Thanks a million to those who could say something back. Kind regards!.
Where are you reading that? getinfo is not deprecated nor is it being removed. Even if it were deprecated, it would be removed several versions later. |
|
|
|
NOTE: Moderated topic.
I think you forgot to hit that self moderate button. It would be relatively easy to make the blocks contain hashes of off-chain bundles that record additional transactions. These bundles could then be whatever size, or they could be one-megabyte and there could be dozens or hundreds as needed.
Nodes getting just the blocks could then easily verify that a block chain has grown from the genesis block and see how much proof-of-work it contains, allowing them to pick valid longest-chains without tracking the bulk of transactions.
I don't quite understand this. Are you talking about full nodes here? If so, then the full node would still have to download all of those bundles, verify all of the transactions, make sure that they hash to the hashes in the block, and check that that hashes to the merkle root. The bandwidth requirement is still the same and the CPU overhead is slightly higher due to more hashing. A full node has to do this otherwise a malicious miner could be producing malicious blocks or just adding in arbitrary hashes. Spending a txOut would require transmitting both the merkle branch of the txOut in the current txOut set (to show that it hasn't been spent) and the bundle containing the tx record where that txOut originates (so that the client can check the old transaction). The receiving client could then check the validity of the txOut.
What is the "merkle branch of the txOut"? And, poof. You create another level of "lightweight client" that checks the block chain itself but doesn't check individual transactions except for those transactions that directly affect it.
It isn't very lightweight if you are still downloading 60+ Gb of blockchain, although I suppose it is lighter than the requirements of a full node. And the block size no longer limits the transaction rate.
So it would scale better, or at least it wouldn't fail with a hard limit when transaction rates increase.
Right, but then what happens when someone decides to spam the network, as we have seen in the past? This brings back the old argument against having an unlimited block size, which is what you have essentially proposed. But would it scale better *enough*? Regardless of how it's done, lifting the tx rate limit means increasing the bandwidth/storage limit for anybody who's downloading and checking the full transaction record - by the same amount as
if you had increased the block size limit itself. Because, ultimately, they are the same limit.
It would allow more transactions, but you would eventually run into hardware limitations and potentially stop many users from running full nodes due to the bandwidth and storage requirements. This is a centralizing factor. One advantage to miners over just increasing the block size: you'd only need to download the block itself to get the ability to form a new valid block, so you still get the propagation times etc of one-megabyte maximum-size blocks. You aren't particularly penalized for bandwidth, provided you can use your bandwidth FIRST to get the block and THEN start downloading the bundle.
The disadvantage is that miners who haven't yet finished downloading the transaction bundle would risk orphan blocks if they include any transactions that were available before the previous bundle because they wouldn't know yet whether those tx were in the bundle. So if a tx didn't make it into the very first block it could have been in, it might be a long-ish time before anybody would risk including it in a new block.
As sdp, a miner would still have to download the bundles and verify before mining otherwise the block he is building on could be invalid. However, many miners are SPV mining so they aren't validating the block anyways or are doing so in parallel. It won't affect them, but it is bad practice to do so. I would also like to point out that changing the block structure to do this would require a hard fork anyways. |
|
|
|
|
The has to do with an issue with binding to ports from the Linux Subsystem. Because Bitcoin Core can't bind to the necessary ports, you can't access it over RPC nor will it be able to accept incoming connections. This is a problem with the subsystem itself so you will have to wait for later releases to fix that.
|
|
|
|
|
If the change is unconfirmed, then it isn't part of your balance and you will be unable to send that change. It depends on how many inputs of your balance are change. Can you show a screenshot?
|
|
|
|
I just removed i send email and get;
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain blockchain.info by aspmx.l.google.com
SCAM
Huh? What are you even trying to say? |
|
|
|
|
Warning! This is probably a scam.
There is no way that any investment can be guaranteed to earn 150% in 10 days. There is no proof of how that will even happen. If this is supposedly done by blockchain.info, there is no indication that they are doing it on their websites.
|
|
|
|
Whats that Testnet error about?
Im using bitcoin-core v12.01 btw.
thanks.
Bip 109 (bitcoin classic fork) forked on testnet apparently. They used version bit 28. So testnet has 2mb limit? Hmm thats a bit annoying for people who want to test standard version. Well I'm not sure. I think it might have forked and there are two testnet chains. It's probably a good idea to ask about this on irc or the mailing list. |
|
|
|
Whats that Testnet error about?
Im using bitcoin-core v12.01 btw.
thanks.
Bip 109 (bitcoin classic fork) forked on testnet apparently. They used version bit 28. |
|
|
|
Hm... I have the feeling that I can't use the terminal well enough, it doesn't recognize the commande bitcoin-qt.
I can go in the right folder Applications where there is the .app file and open it, or use the command open, but I don't manage to execute it in another way...
Ok, so I haven't used a mac in a while so what I said was probably not right as that was for linux (which is similar to os x). A quick google search turns up this: open Bitcoin-Qt.app --args -zapwallettxes Try that and see if it works. |
|
|
|
Thank you, I tried it but this is not the right command. I manage to open Bitcoin Core typing But if y try to insert the option, I get the following error message : $ open -a Bitcoin-qt -zapwallettxes
open: unrecognized option `-zapwallettxes'
Usage: open [-e] [-t] [-f] [-W] [-R] [-n] [-g] [-h] [-b <bundle identifier>] [-a <application>] [filenames] [--args arguments]
Help: Open opens files from a shell.
By default, opens each file using the default application for that file.
If the file is in the form of a URL, the file will be opened as a URL.
Options:
-a Opens with the specified application.
-b Opens with the specified application bundle identifier.
-e Opens with TextEdit.
-t Opens with default text editor.
-f Reads input from standard input and opens with TextEdit.
-R, --reveal Selects in the Finder instead of opening.
-W, --wait-apps Blocks until the used applications are closed (even if they were already running).
--args All remaining arguments are passed in argv to the application's main() function instead of opened.
-n, --new Open a new instance of the application even if one is already running.
-g, --background Does not bring the application to the foreground.
-h, --header Searches header file locations for headers matching the given filenames, and opens them.
I have also tried $ open -a Bitcoin-qt --args zapwallettxes
which opens Bitcoin Core but it doesn't seem to change anything. You don't need the open command. Bitcoin-qt by itself is an executable and can be executed from the terminal. |
|
|
|
Incorrect - you should have realised that the "staking" was only done very recently and her account was years old (it took me all of 1 minute to work that out).
The thing is, some accounts are bought and sold very quickly, usually by account farmers who will buy an account, do some posting and rank it up, then sell it as soon as possible. It doesn't seem that strange (at least to me) to see an old account have a new staked message and be sold off after a few months. Don't lose faith. At some point the community will band together and ostracize these account buyers/sellers that are a cancer to bitcointalk.
I suppose I should stop escrowing these kinds of trades. Or at least make my fees something ridiculous for account trades. It seriously sucks, there was allot of information on that account that I actually use lol. Like how to get the flex src for cam4btc to compile so I can relaunch the cam site. That's actually how I figured my account was hacked.. I was looking back on some older messages because I am having problems building the source so I can change the ip to a new server.
Now i'm kinda screwed. I guess that's a lesson learned always keep hard copies of important messages and docs...
Maybe the current owner of the account can forward those PMs to you so you at least have access to that information. |
|
|
|
Reading a little about SegWit, what I understood that SegWit addresses will be different from usual addresses. So, how a fund sent to a normal address from a SegWit address will be determined by the API?
p.s. I'm sorry if my Q does not make sense. But, I'm getting a little confused here.
Your question is not clear. What are you asking about? The API's node will have to be segwit compatible in order to understand the outputs. |
|
|
|
Thank you all for your quick answers.
This is indeed Qt version 5.2.1, Bitcoin Core version 0.10.2, running with Mac OS X version 10.6.8
Could you explain me how to use this zapwallet option ?
Open the terminal. Type bitcoin-qt -zapwallettxes Hit enter. Bitcoin Core will start and it will do everything it needs to do. Once its fully up, you should see that the unconfirmed transaction is gone. Shut it down and start Bitcoin Core normally. |
|
|
|
Also I don't know if you read my first comment but how can you be 100% sure she didn't sell her account herself from a sockpuppet and now she's trying to get it back while keeping the BTC she received for it?
I'm not saying that's what she did, I'm actually fairly certain she's a victim here but you can't overlook this possibility.
This is the key problem. The admins can check the IP logs and see who has accessed the account and check if the IPs match, but even that is not definitive because people can use proxies and Tor. The account which sold it was also clearly a throwaway.
I also think this issue if further support for showing the user the IP addresses of recent logins to their accounts so that people can see if someone else has hacked their account but did not change the password. |
|
|
|
|
Because the transaction is very old and remained unconfirmed, the network dropped the transaction. Block explorers don't show it anymore because they "forgot" it.
The solution is to start bitcoin core with the -zapwallettxes option. How to do this depends on your OS. As merelcoin said, it will clear the unconfirmed transactions from your wallet and allow you to resend the coins.
|
|
|
|
This is what my dashlooks like.. All those negative transactions, I never made them. You can not get transaction info from them. I deleted all databases and rebuilt.. took me 4 days, same problem... I need to get my wallet into bitcoincore and test there but I don't know how.  Did you rescan the wallet. Not rebuild the database but rescan the databases. There is a difference between the two, and rescanning shouldn't take as long. Are you able to copy the transaction IDs of those transactions and post them here. If there is a bug then those txids will not match what the transaction supposedly is in your wallet or they may not exist. I am unable to download your log. |
|
|
|
|
Bitcoin core will reject and transaction with an "absurdly high fee". This means that it will not accept it to the mempool and will not relay it. I don't remember what the exact threshold for this is, but I think it is actually fairly low.
|
|
|
|
But in this case we don't have 65 byte key (nor 33 byte key) but only push 72-73 byte value.
Yes we do. You are not understanding how the scripting system works. The 73 bye value counter tells the software that the next 73 bytes of the transaction is for the output script. It is not part of the script itself. That script then pushes 65 bytes to the stack. Then OP_CHECKSIG. OP_CHECKSIG interprets the previous item on the stack as the public key and the item before that as the signature. There is nothing that marks then as being the signature or public key. |
|
|
|
Version 1 was introduced in the genesis block (January 2009). •Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930. •Version 3 blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a soft fork. When the fork reach full enforcement (July 2015), it required strict DER encoding of all ECDSA signatures in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012). •Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2 •(November 2015) as a soft fork became active in December 2015. These blocks now support the new OP_CHECKLOCKTIMEVERIFY opcode described in that BIP. per the Bitcoin Developer ReferenceHe's taking about the coinbase transaction being version two instead of version one, not the block version. There of no difference between version one and that transaction that is supposedly version two. It is the same format, just that the miner changed the version number to two. I'm guessing it had to do with a bug in the mining software since the block version number was being bumped to two as well around that time. |
|
|
|
|
Show Posts
