|
Try switching to a different server.
|
|
|
|
|
Your transaction is confirmed, so you have received the Bitcoin. This is a problem with your wallet.
Is your wallet connected to the network? Is the server it is connected to behind?
|
|
|
|
Has there been any formal announcement about revoking Gavin & Jeff's commit access?
No. |
|
|
|
No. I tried to start it, but it asked if I would let it alter the database so I figured I'd better wait for some help.
What is the exact message that it gives you? Can you post a screenshot? Armory cannot work if Bitcoin Core is not running. |
|
|
|
|
Is Bitcoin Core running when Armory is running?
|
|
|
|
when is btc2x fork taking place? i see BCD is already gaining lot of attention although supply volume is massive than BTC core.
thank you all...
2x was canceled. Bitcoin Gold, Bitcoin Diamond, Bitcoin Cash, etc. are completely different things. |
|
|
|
Thanks for your reply. I'm not sure. I mean, there must be a way to check if the blockchain loading is complete without checking how many blocks do currently exist first and then compare this number with the number of loaded block.
I have something in minde like "bitcoin-cli -proof-completeness" and getting "yes" or "no" as a result. I just want to know when the system is ready to spend any funds.
This is not possible. Bitcoind does not and cannot know when the blockchain is actually fully synced until it is fully synced (and even then it technically doesn't know it is synced). The best you can do is check the blockchain height. There is a variable called IsInitialBlockDownload and in the next major release of Bitcoin Core, that variable will be included in the getblockchaininfo output. That is what tells the GUI to show whether it is in syncing mode or not, but IBD can be set to false before it is actually fully synced. |
|
|
|
|
What happened was that Cobra, one of the Bitcoin.org domain co-owners, pushed a blog post to Bitcoin.org without a Pull Request. This means that he did it without consulting the contributors to the project and there was no review of the post itself. This action itself was controversial. The commit was reverted later because it had been done unilaterally without anyone else's consent.
The other problem isn't so much that Knots would be hosted there but rather that Bitcoin.org would be promoting Knots instead of Core. Knots, while based on Core, has experimental things merged and does not have as much review. There are also a few other controversial changes such as address blacklists that luke-jr implemented in it himself.
|
|
|
|
Thanks a lot. However, I want to compile it myself for my PC and 2 nodes which are running on Devuan distro. I was actually wondering myself because there is actually no source tarball on https://bitcoin.org/en/download. There is a link there that brings me to the github repo. So I guess the only source tarball in on github. All of the released stuff (source tarballs, binaries, etc.) can be found here: https://bitcoincore.org/bin/ and https://bitcoin.org/bin/. You should use the source tarballs that are distributed from those places as those are the ones that are deterministically built and PGP signed by the release maintainer. |
|
|
|
|
First of all, transactions are not lines or strings. They are just data in a specific format.
You can store any sequence of bytes (aka any data) that you want in the blockchain. However just because you can does not mean that you should. Storing your data means that thousands of nodes must also store your data, and that is a lot of disk space and computer power that needs to go towards storing your data for eternity. Storing arbitrary data on the blockchain is rude to node operators and everyone else that uses Bitcoin as you are taking up block space that could otherwise be used for actual transactions. So yes, you can store data, but you really shouldn't.
|
|
|
|
I don't really see why people would use this in bitcoin
There are some coins that do a "Proof of Burn" where you must burn Bitcoin in order to mine (or something like that) on the altcoin. |
|
|
|
|
No, you can't do that. The best you can do is have your wallet only connect to your raspberry pi and only sync off of it. But this won't help with the time required to catch up.
Alternatively you could use Electrum and setup your own Electrum server (full node with some additional things; requires bitcoind) on your raspberry pi. This would let you use your own full node but not have to wait a long time every time you want to use your wallet. However I don't know whether a raspberry pi is capable of running an Electrum server.
|
|
|
|
|
If you don't have any wallet files or your password, then there is nothing that you can do.
|
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
Wouldn't it make sense to normalize the block storage format?
That would make it practical to do various operations between computers, like fill missing data or compare/verify.
The block storage and file formats are normalized. What you can't do is ensure that every single node has exactly the same data in exactly the same order. This is because during normal operation, orphan blocks will cause nodes to receive different blocks in different orders. Some nodes might see a block which another node does not see at all. Or they might see two different blocks and write them in the same position. Because of orphans, it is not possible to make all nodes have exactly the same data in exactly the same order. During initial sync, having to write the blocks to disk in blockchain order rather than order received will result in a slower sync. Why XOR the chainstate data or (index?) database files?
To prevent antivitus software from messing with the database files because sometimes they contain virus signatures because virus signatures are embedded into the blockchain. Having the database files corrupted will require the entire database to be rebuilt which will take a long time. |
|
|
|
Content is XORed with random key, so that antivirus software does not trigger.
The block files themselves are not XORed with the random key; the databases are. |
|
|
|
Ahhhh did what achow said on both computers. Seems to have worked now. Just awaiting confirmations, will probably take a while because I sent low fees. Such a dick head  Your transaction may not necessarily reach all nodes. Both of your wallets will see the transaction once it has confirmed. But since you have broadcast it a second time through your second wallet, it should be fine. |
|
|
|
Hi, I have the same problem as the OP, I invalidated that block, and the sync will not resume anyway. How is deleting the portion of the block chain as you suggest done? Now bitcoin abc is stuck at 478557. Thank you
Stop Bitcoin Core. Go to the Bitcoin Core datadir and then the blocks folder within that. Delete the highest numbered blk*.dat and rev*.dat files. Then start Bitcoin Core. It will say it needs to reindex, let it reindex. |
|
|
|
Please do not make duplicate threads.
Go to the transactions tab in Bitcoin Core. Right click your transaction and choose the "Copy raw transaction" option. Open the debug console and type sendrawtransaction <copied raw transaction>
where <copied raw transaction> is where you paste what you copied. Hit enter and the transaction will be sent. |
|
|
|
|
Show Posts
