Hi,
I sent a transaction using 0.11.2 and the recommended fee for "normal" confirmation time over 6 hours ago and it's still unconfirmed.
Has the default fee become too low somehow?
Cheers
What wallet software are you using? Bitcoin Core? What version? If so, did you let it run for a while so it could determine what the optimal fee was? |
|
|
|
|
Is there a reason you are downloading the block chain vs just running Bitcoin core? Since 0.10.0 it hasn't been any faster to do so, and may be slower.
|
|
|
|
Was trying to find out how the guy is doing this without any success, this is just driving me nuts.
He has more hashrate than you and is mining more blocks than you in some period of time but he is not broadcasting them or network has issues with data progagation. Then he broadcasts all new blocks or network data propagation improves somehow. He is possibly an owner of all full-nodes on network except yours so data propagation is up to his likings. But in any case, he has more hashrate than you. What doesn't make sense is that even if he had more hashrate than me, he would find the first block faster but then difficulty would adjust right away and finding the next block will be equally as hard as finding it in my chain (yes thats how broken it is) and then it is only a luck game. So on this alt, difficulty adjusts after each block? Perhaps he has a modded octocoind that doesn't adjust on each block? So perhaps he just mines a long chain without broadcasting it and without the difficulty readjustment, then broadcasts it which orphans everyone else's blocks? Higher hash rate, greater total difficulty, he wins? |
|
|
|
How can someone achieve that? I am running a pool which represents 70% of the coin's network hashrate, I can find few sequential blocks then this miner will mine the next block and orphan all of my previous blocks.
Additional information:
- My blocks are broadcasted/propagated normally (checked that)
- Changed IPs, Changed daemon versions and nothing helps
- Made a separate network that gets connected to the mainnet once every few hours, and this also didn't help !!!
How the heck did this miner achieve this and what can I do about it ?
What coin is this? |
|
|
|
|
You can also try checking to make sure all your drivers are up to date - see Device Manager, assuming this is Windows. Likewise, it doesn't hurt to use chkdsk to see if it is a hard drive issue and you can try running Windows Memory Diagnostic.
These should at least help you try to find anywhere you are having the issue.
|
|
|
|
Having a bunch of "free space" that's unused due the cap being too big brings a lot of problems and possible exploits. What centralizes Bitcoin is not being able to run a node in your computer, not the nonsense you are talking about. Bitcoin will never scale to worldwide levels by raising blocksize.
There is no free space. Damnit you guys really have no clue about the blocksize debate and comment on it. The cap limit is not a default setting. Blocks wont become 8mb size, and 7.5 mb will become empty. Blocks will remain the same 0.5mb, but it just lets the maxium reach 8mb if it needs to. Now i dont think 8mb should be increased immediately, but it should be written into the protocol to increase at some point. I dont like the command & control aspect of the development. There should not be a need for development anymore. Add a final BIP into it, and then its over. Developing it further just gives more power to the developers and it creates a centrally planned currency, that is nothing better than fiat. I know there's no "default setting" and free space is just a way so say it, but yes having that "extra space" brings some problems. In any case 8mb or 20 solves nothing in the long term. Right now those values are absurd, in the future, we'll see how the average internet connection/hardware deals with those, but the main point is, Bitcoin will never scale to worldwide levels without something like the Lightning Network. At some point software solidifies, protocols need to stop being exposed to hard forks, and 1mb seem to be enough (+ sigwit) until we get LN. Only people clueless in scaling software of this nature would claim that doing hard forks periodically is a good idea. TCP/IP solidified and then we developed layers on top, the same will happen with Bitcoin. I don't care if it happens with 1mb or 2 or 8, in the long run we will encounter the same problem and only LN can save our asses if we want to go global, something big block guys don't seem to get (unless they are ok with the nightmare of huge datacenters running nodes + the aforementioned problem of periodic hard forks). I agree. At some point, bitcoin will be too entrenched to do hard forks unless absolutely necessary - e.g. some huge break in ECDSA, perhaps proving P=NP would make things absolutely necessary. LN, sidechains, segwit and similar proposals are ways to alleviate the pressure on block sizes and accomplish a lot of experiments without having to change the core protocol regularly. As above, I'd think about it like TCP/IP vs SMTP/DNS/FTP/IMAP/NNTP/SSH/DHCP/HTTP and the like. Much will be built with bitcoin's blockchain and on top of it due to the security that the value of the bitcoin ecosystem provides. |
|
|
|
You could have a block that is corrupted on disk which might mean re-downloading the block chain. Mine always crashes around the same block. Then starts over from block 1, 'reading the blockchain', with 1 core. Which takes forever, and then gets an error and aborts again after 10 hours or so. like this 2016-01-05 11:53:27.625338 LoadBlockIndexDB: last block file = 410
2016-01-05 11:53:27.629531 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=94, size=60445069, heights=391569...391856, time=2016-01-03...2016-01-05)
2016-01-05 11:53:27.629589 Checking all blk files are present...
2016-01-05 11:53:27.700450 LoadBlockIndexDB: transaction index enabled
2016-01-05 11:53:27.700552 LoadBlockIndexDB: hashBestChain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03 18:15:05 progress=0.000000
2016-01-05 11:53:27.701030 init message: Verifying blocks...
2016-01-05 11:53:27.701201 block index 16563ms
2016-01-05 11:53:27.701415 No wallet support compiled in!
2016-01-05 11:53:27.701433 init message: Activating best chain...
2016-01-05 11:53:27.764422 - Load block from disk: 0.36ms [0.00s]
2016-01-05 11:53:27.764506 - Sanity checks: 0.03ms [0.00s]
2016-01-05 11:53:27.764534 - Fork checks: 0.03ms [0.00s]
2016-01-05 11:53:27.764586 - Connect 1 transactions: 0.05ms (0.050ms/tx, 0.000ms/txin) [0.00s]
2016-01-05 11:53:27.764602 - Verify 0 txins: 0.07ms (0.000ms/txin) [0.00s]
2016-01-05 11:53:27.764653 - Index writing: 0.05ms [0.00s]
2016-01-05 11:53:27.764678 - Callbacks: 0.03ms [0.00s]
2016-01-05 11:53:27.764695 - Connect total: 0.30ms [0.00s]
2016-01-05 11:53:27.764710 - Flush: 0.01ms [0.00s]
2016-01-05 11:53:27.764725 - Writing chainstate: 0.01ms [0.00s]
2016-01-05 11:53:27.764782 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 log2_work=33.000022 tx=2 date=2009-01-09 02:54:25 progress=0.000000 cache=
0.0MiB(1tx)
It verifies the blocks starting from 1, with a single core. Attempting a 'bitcoin-cli stop' says that it's currently reading block index, lol. I had more success w/ the XT client, but I don't think they're really much different at all? |
|
|
|
Doesn't the blockchain need Bitcoin to function and visa versa?
Right now the value of Bitcoin helps secure the block chain. It isn't "needed" in a strict sense to function, but to function securely in a distributed environment, the value provides the incentive to do so. |
|
|
|
Well, the first one says there is no such directory as C:\Users\New What is the name of the user you are using? You can find it like this according to this depending on windows: Follow these steps to find out what "User" name you are currently logged in under, on your laptop:
Press the Ctrl + Alt + Delete keys simultaneously.
Windows Task Manager will pop up on the screen (see picture below): Click on the Users tab. Look under the User heading for your currently logged in account. from: http://library.queensu.ca/libguides/computers/windows-username-check.htm : |
|
|
|
You might try moving this into here since that is the multibit section. ;-) https://bitcointalk.org/index.php?board=99.0Hi
please help me understand this.
1. during the installation of multibit HD i wrote down the so called "wallet words".
2. with this wallet word i can restore my wallet.
Q1: if i forget the password of the wallet i can restore it with the wallet words?
3. to every BTC-Address there is a pair of keys.
Q2: is this correct?
4. i have a wallet and within this wallet i can have any number of addresses.
Q3: correct?
Q4: all these addresses are restorable with the wallet words?
Q5: which part/files do i have to backup exactly?
and the last question.
Q6: if know the wallet words. i make a backup today. tomorrow i generate a new address to receive a payment. then my pc gets lost. can i claim the BTC a received with the address generated after the i made the backup?
thanks a lot.
|
|
|
|
No worries, thanks for replying.
I have Core already installed and replaced the wallet.dat file with mine backup. I've rescanned and it's now downloading 5+ years. Seems to be going fairly quick.
It will go quick......'for now'. Wait until you hit 2 years to go  Boom! Yeah you're right. Stuck in the mud now. Wow, I wish there was a better system for this. :-) It's worth it in the end, the security & having control of your private keys is worth the wait rather than using online wallets etc. You can export the private keys from Bitcoin Core and import them into a different wallet. You don't need online wallets or things to be fully sync'd to export the keys. |
|
|
|
... I can't wait to see BU (fail to) deal with 16/32MB blocks trollishly construed so as to take hours or days to verify. ... This is an important point - and the one I've thought it safe to ignore here, but if you have people picking a larger sized block, without BU building in safeguards, it will be dangerous to the network if people are not aware of the consequences. Even 2 MB blocks can have transactions that can take 5-10 minutes to verify. |
|
|
|
This. Right now the only difference is a nice front end to change a parameter (ignoring again other issues to keep the network secure). Even a non programmer can edit it easily. "user-selectable blocksize cap" aspect -
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
3) They all start producing 200MB block.
4) I fill up the blocks for the next 10 days
5) Bye bye 75% of all network nodes
6) I pretty much run the network
Here's the difference with Core: 1) So I fire up 2000 nodes, hire a coder to mod the Core code to set 200MB as cap. 2) I make the miners belive this is the prefered block size. 3) They all go "yayyy tons of fees!" and hire a coder to mod the Core code so they can start producing 200MB block. 4) I fill up the blocks for the next 10 days 5) Bye bye 75% of all network nodes 6) I pretty much run the network Not that you could actually do (2) anyway, but that's just me defending Core again. As I mentioned, this is just a bit more convenient in BU. Someone with the resources to spin out 1/3 of the total number of nodes now on the network, and mining pools that are actually mining the blocks now, are going to find it trivial to do (1) and (3) right now, in Bitcoin with Core, if they wanted to. The convenience of BU is not going to be of any noticeable help, and even if you think it is, that horse has left the stable - the miners convinced can just download BU. Under that view, all that was necessary to kill Bitcoin was to release BU. That can't be right. |
|
|
|
Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something? Well, that is already the case. BU just makes it more convenient. It is far easier and less expensive to spin up a bunch of nodes than replicate replicate the hashing power. Would you agree or disagree? They don't even have to break off and form their own chain. They can just recompile with a parameter changed to accept larger blocks. And then in theory that larger block would be orphaned and it would go back to the main chain eventually. (There are other considerations for say allowing 200MB blocks with regard to just changing that parameter, but safe to ignore them in this reply I think). |
|
|
|
Hello sir or maam
I just want to ask if the old electrum version can be effect while sending or receiving bitcoins?
My electrum version is 2.4.3
You should move it to here which is the electrum section: https://bitcointalk.org/index.php?board=98.0Thank you sir for fast reply and sorry for the wrong section. I will move it in electrum section thank you. Cool. They'll know the answer there, most likely. ;-) |
|
|
|
Hello sir or maam
I just want to ask if the old electrum version can be effect while sending or receiving bitcoins?
My electrum version is 2.4.3
You should move it to here which is the electrum section: https://bitcointalk.org/index.php?board=98.0 |
|
|
|
Hmm... I wonder if the problem is the CLTV value itself: What block number is that (am a bit tired and really starting to hate Satoshi for using little-endian)? Looks like 629420 to me too. |
|
|
|
Been running 0.11.1 since it was released for a while and only ever had blkxxxxx.dat in the "blocks" folder. Never had any revxxxxx.dat files until forced to re-index.
Some references: http://bitcoin.stackexchange.com/questions/11104/what-is-the-database-forblocks/rev*.dat: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations. https://en.bitcoin.it/wiki/Data_directorylocks subdirectory
[v0.8 and above] Contains "undo" data.
rev*.dat
You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.
https://bitcoin.org/en/release/v0.11.0 |
|
|
|
The illusion of the U.S. Dollar’s intrepid strength is a false indicator that the American media has been trumpeting since late 2013. It is an indication of its value relative to other fiat currencies like the Euro and Japanese Yen. Kind of like a battle for which debt-based bearer bond is the best at losing value the slowest. Well, CNBC has published an admission piece on how Bitcoin’s dollar price shames the world’s reserve currency in a battle of relative strength for 2015. Eric Rosenbaum’s article has an odd post-mortum twinge to it, starting off with “The U.S. dollar has had a nice run.” Plenty were saying that about Bitcoin’s value at the end of 2013, no? Even so, U.S. Dollar index value has risen almost 10%, which sounds impressive enough. Yet, Bitcoin over the same period is up over 40%, which is somewhat misleading, at that. Bitcoin value hadn’t finished recovering from the Mt. God bubble/collapse, and dropped to under $180 in midJanuary, from over $300 USD at the start of the year. Bitcoin is up well over 100% since its darkest days, which is not mentioned in the piece. http://www.newsbtc.com/2015/12/30/28290/That sounds like some weird fetish. :-) (Typo is in the original) |
|
|
|
|
Show Posts
