|
You should have installed the 64bit version if you have a 64 bit OS. It shouldn't need to redownload or reindex as long as you keep the data directory. The same data directory can be brought to other computers as long as they are the same OS (e.g. windows to windows, linux to linux) since windows to linux and vice versa causes a reindex for some reason.
|
|
|
|
RAM.
Restart the node and you delete all pending transactions and start from scratch!
Doesn't work like that. You need everyone to shutdown and boot up at the same time. As long as one node is up, it will send all of the transactions it knows of to everyone. Agree to disagree? My experience is that an upcoming node will only listen to new incoming tx relayed by the peers - it won't ask for the full outstanding list of standby tx from its peers. If I am incorrect, please provide me with the codebase. When I restart my node, my "getmempoolinfo" starts with 0, and then grows with time - not because I receive the full list of outstanding tx from my peers, but because it matches the rate of "fresh" incoming transactions. I have learned to do this by being an Electrum-Server. I use to restart its Bitcoin daemon once a week, to get rid of the unconfirmed transactions that clogged the RAM - this week, I am doing it daily. In a way, it is not bad, if everyone would do that, it would allow payers to resend their coins (which are still not included into a block) with a higher fee, without being discarded by the nodes as a "double spent". I'm pretty sure that you will still end up with all of the transactions that are in the mempool anyways, or most of them. When your node receives a transaction, it will check its validity, and in order to do that, it must have its parent. If it doesn't have the parent, then it requests it from other nodes. And so on and so forth. If someone was spamming the network with the transactions go down a chain (e.g. A -> B -> C...) then your node will still get all of those transactions because it requires the parent to validate a transaction. Other spam where 1 parent has multiple children may not cause your mempool to fill up because it does not see all of the child transactions. However, once a transaction that consolidates all of the micro transactions into one address comes out, your node will still have to request all of those micro transactions and still fill up your mempool. So you will pretty much still have to get all of those transactions again from somewhere and fill up your mempool. |
|
|
|
I'm not so sure since those timestamps show the files being modified. Bandwidth was taking a hit too but it's possible that that was just because I quit my client a few days ago.
It's looking like I probably need to copy the whole of the blocks directory and the chainstate directory too. I'll give that a go and see how it works out.
Worst case, I should probably be able to just tell the bitcoind on linux to use my windows node as a peer and get the blocks that way.
The timestamps modify because it is reading from each file and the act of opening and reading a file will modify its timestamp. It needs to read the blk files in order to build the other leveldb files. |
|
|
|
Oh, I see. I though you were talking about priority earlier. I didn't realize that.
ok, when i first saw my transaction it showed Network Propagation :3% - 34 Nodes - (Very Poor) after sometime Network Propagation :0% - 0 Nodes - (Very Poor) again after sometime Network Propagation :4% - 40 Nodes - (Very Poor) why all this is changing if the miners are fixed then how can the percent change with time and is there any role of nodes in confirming a transaction? Nodes don't really have a role besides validating your transaction and forwarding it to other nodes. If your transaction isn't spread very far, then it is unlikely it will make it to a miner to mine into a block and confirm it. The number of nodes changes with time because nodes go up and down constantly. With few nodes, if some of them go down, they won't relay it to other nodes (duh). However, your client continuously broadcasts it so other nodes will pick it up and relay it so it propogates through the network and reaches miners. |
|
|
|
I believe they are behind this attack and if not they are contributing to it by spitting out empty blocks and not properly validating incoming blocks.
There is no valid reason for any pool to be propagating out to the network empty (and unverified) blocks when we have a backlog of over 50k transactions.
We need to put them in their place. We have the power to fuck these guys over if they don't want to follow the rules we set forth.
Edit: we start by targeting one pool and with any luck the other pools will get the message.
They don't have an incentive for this attack. It is a waste of resources. Still, empty blocks are not intentional, they are accidental. Even if you did do this to one pool, you would not see results immediately. They need to rewrite a portion of the code and test it before deploying said code. It will take longer than a few hours, and by the time the code is deployed, the attack will either be over, or the pool will no longer be in operation as all their miners have left. The portion they are rewriting would be for either getwork or getblocktemplate from Bitcoin Core because those are the parts of code that create the block parts and the header. You are just going to waste your time and effort and resources by DDoSing them, and it won't help the network either as it will decrease the hashrate thereby increasing confirmation times. If you want to help them and remove the empty blocks, why don't you go checkout the code for Bitcoin and write a patch that prevents empty blocks yourself. This way, you can actually see results by distributing the code to miners if you DDoS them. Of course, that is also blackmail and frowned upon. mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?
RAM. Restart the node and you delete all pending transactions and start from scratch! Doesn't work like that. You need everyone to shutdown and boot up at the same time. As long as one node is up, it will send all of the transactions it knows of to everyone. mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?
Depends on the computer. Whenever it runs out of memory, processing power, or bandwidth. When that happens, the computer will either crash, the software will crash, or its network will go down. |
|
|
|
] I just see few terms like : poor , good , high priority ...
I don't think these two are related... But i think these terms are related to Network propagation as i see : Network Propagation :3% - 34 Nodes - (Very Poor) in my transaction. Oh, I see. I though you were talking about priority earlier. I didn't realize that. |
|
|
|
|
It isn't redownloading, it is reindexing the blockchain. It doesn't take as long to reindex everything. I have run into this problem before. For some reason, Bitcoin Core doesn't recognize the databases from windows and vice versa. Just let it reindex the block chain, it will take considerably less time than a redownload since you already have the raw block files, it just needs to rebuild the databases it uses.
|
|
|
|
I hope I"m wrong but I don't think we have time to find a good solution we must act now before its to late. Transactions propagation time across the network is growing at a huge rate. Attacking the mining pools will only buy us a little more time. With any luck the devs will figure out a solution. https://getaddr.bitnodes.io/dashboard/?days=90Why are you so intent on attacking the mining pools? They already are under attack, as well as anyone running a full node. Attacking them with a DDoS is NOT going to help at all. It won't buy you any more time, it will just make this worse. |
|
|
|
Is this only a small linux version or is it "the" version for linux based original wallets?
It is NOT "the" version for linux, simply the one that you would install from the package manager for the distribution of linux called Gentoo Linux Its like bitcoin-qt, only for linux. But is it "the" biggest linux version used? That would be really huge and an even bigger attack. Surely it will only work for solomining since the transactions are only checked manually by the miner.
Gentoo linux is not the biggest distro of linux used. The most commonly used one is Ubuntu or Debian. |
|
|
|
|
Seems good. I think you should have the outputs in a way to have everything broken down and apart instead of just returning the JSON object.
Also, maybe have each command in a drop down list and the user selects which command. Then the page has a description of the command and some text boxes to enter the parameters and such instead of having to enter the command as if it were the console. This would make it much more user friendly, especially to those who aren't familiar with using Bitcoin's console.
BTW, this belongs in project development.
|
|
|
|
hmm, i think i'm starting understanding..., sorry i'm like a noob at technical area from bitcoin... i just use it lol..., so the fee is for miner who'll confirm it but i still don't understand well how this re-push works, how you got this code? 0100000005dcd2b41d5bc4901eda4d231d31e93142820b990229193d73ff14debfa6995e4601000 0006a47304402201181e80a9b04af821015b4aef64b7232c35c6560c1fd2a6c74f758f57c7c93fc 02201d177e2070ff242b6bee8965252fab37aa2b8489ce2c1b31339e72d3f11bd3ea0121024c21b 7e69f518a9aef328a6cd3c5ea3210a6f179132f3048709017498a308877ffffffff0c1ed07e35dc ce7af485274d47950cdde773ca933854f0927e792832447bd79b000000006b483045022100cd2d0 79cbf13244b4239086a1475a73ed28f875362ad8008093991c0188c10df022039b7cdbe97550b00 d9563d164336ca7eebcc8e1cd31a13503ae7d03866fb8b9a012102f7798d086be181be448739458 3845b9d1a068fd9d556d8c09e9184514ea93940ffffffffaaa18a166d75865cc3e83b746d902f43 fb97e4a2131d22676c42f02aac34c5ca010000006b483045022100ab41f7cc1b2842afb13532b64 458ab6ff1abeee7e77d02e6fea95943307fddeb02200c2accc3c44109c8d9140cf5b63a4ad97166 3e71567cc8376326165214981f670121028a1b335c72e6d45bbf69e68f2a53b9334835f4c3ee6ee e51b8b9db98f79bce97ffffffff404faac96dd69eabea60ce0a593bcc50072214865a21d9e1fbf4 49459ac39153000000006a4730440220139647c941c22a1057819d713d3b0dfc135bae940f51918 236c562791dcec6d402204a0900f6fe47da61d1e01e999a9326c65bb5d35f62c93bae1ed206a924 62c97b012103a0e56a757503f6aef59b3edc6420db962d58c2780b0f6ae1aad524cc4feb2d96fff ffffffbd70e8a98fbc691bb143daaa4126c2eb4ef2e6ba2ed1167b522d7e859303615010000006a 47304402205ed98ca834c27119d8eb85e8fc66b860703b0f44cb64bf068e816ccd31a1db7802200 2e48f79e9b8a1dea0372061b615292b9f81beea2957170410b92b726acb548b012103dbc1fc5554 a6ba5a1f5cae93729b86b4772e004830818b0ce24d7e2784409e6cffffffff0290683e000000000 01976a91459969991bab4b61778540ffe8ad02b2244ee243b88ac8f5d1000000000001976a91409 0672efce2b22b7ad64c36f2172c4b7470b5e4a88ac00000000 and what https://blockchain.info/pushtx exactly do? Thanks man, you helping me alot ^^ The code is the raw hex of your transaction. This is what gets sent between nodes. Just copy and paste all of this into the link and click submit transaction and that transaction will be resubmit to the Bitcoin network for it to reach miners and hopefully become confirmed. |
|
|
|
|
You have a low fee and there is an ongoing spam attack that is causing delays. Just wait a while for it to confirm. If you don't receive your Bitcoin when you should, contact their support and be sure that you have the letter of guarantee. Since they are a legitimate service, they should still send you the Bitcoin even after the time is up.
|
|
|
|
I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays.
When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork.
That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle.
They do, but right now there is no active fork. There was also no active fork when the delays began, so the fork and the delays are unrelated. |
|
|
|
hmm, i got a transaction 2 days ago... and until now it was unconfirmed (no double spend confirmed)..., and i checked now... and it just disappeared from my blockchain transaction logs lol...
can anyone explain me what happened? how can i recovery it? D:
It was "forgotten" by the network. The network will drop unconfirmed transactions after a few days to keep the mempool lower. Just resend the transaction. Nothing happened to your Bitcoin. |
|
|
|
We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.
Soon the weaker full nodes with less memory and storage capability will begin to slow down and some may even crash.
To run a full node you must load the whole mempool when you run out of RAM it will be pushed onto the HDD or SSD but this will slowdown validations
network propagation. The network could become unsynchronised leading to numerous and repeated forks.
We must act now before it is to late. We must attack all mining pools who mine blind and dumb and any pool who mines empty blocks.
I don't think you understand how this works. First of all, every mining pool mines empty blocks. It is simply the nature of mining that happens to produce empty blocks randomly. They are not intentionally nor maliciously created. If you were to DDoS every pool that mined an empty block, you would DDoS the entire network. There may be some pools that create more empty blocks than others due to having a higher hashrate thus increasing their probability of finding a block soon after the previous. This does not give the miners time to include transactions into the block. Here is some recent data on empty blocks As of block 364125, there are a total of 85,422 empty blocks.
AntPool: 5.16% of their blocks are empty, latest one was today.
Discus Fish: 2.88% of their blocks are empty
KnC: 2.88% of their blocks are empty
Eligius: 2.26% of their blocks are empty
As you can see, AntPool and F2Pool (Discus Fish) are creating the most number of empty blocks. They also consist of about a third of the miners. If you were to DDoS them, then you would lose a third of the hashrate, thereby increasing confirmation times, causing more transactions to fill the mempool and cause a greater backlog. This idea in general is terrible. |
|
|
|
We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.
Wait, I don't understand. If they are mining empty blocks, then they are not processing ANY transactions, but just taking the generated btc? This sounds like another flaw in the system. It could be flaw now, but in the past, it was the only way that Bitcoin could survive. These empty blocks happen because they are usually found within seconds of the previous block, thereby not having enough time to include transactions because of the way that mining works. Empty blocks are not an attack on the network and usually aren't intentional. |
|
|
|
Whats the Significance of Network Propagation in Bitcoin Transaction.
Just be specific to the point , dont tell the meaning of network propagation , do let me know its significance in confirmation of a transaction.
I just see few terms like : poor , good , high priority ...
I don't think these two are related... If your transaction does not propogate through the whole network, some miners may not receive your transaction thereby not including it in any blocks they confirm. If it doesn't some of the larger miners, it may not be confirmed quickly because larger miners have a higher probablility of finding blocks. Q2. whats the maximum time a transaction can take to confirm?
It is possible for a transaction to never confirm. |
|
|
|
This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions. None of the delays were due to the fork, people posting here about tx fees and delays are posting in the wrong place. Fork is done and over, don't know why this thread still persists. There have been forks in the past, there will be more in the future. Carry on. The fork is over, but the situation persists because miners have yet to update their software. There is still a small percentage of miners that could cause this type of fork to occur again. There was another fork late July 5th and there is still the possibility for another fork. I don't think the SPV Miners have confirmed whether they have patched their software to do full validation so the alert remains and the situation persists. The delays aren't due to the fork, but since they happened so close together, people are thinking they are the related, when they are actually not related at all. |
|
|
|
|
It has two confirmations. The reason for slow confirmations right now is an ongoing spam attack on the Bitcoin network. This is increasing the number of unconfirmed transactions and is affecting how many legitimate transactions are actually included in blocks.
|
|
|
|
|
What you need is Child-Pays-For-Parent (CPFP) where you create a transaction with a transaction fee for two transactions. Unfortunately, most pools don't use this yet. If you look around in the mining section, you may be able to find a pool that does this and you can relay both of your transactions to that pool in hopes that it finds a block and can confirm your transaction. Otherwise, the best you can do is wait. After this spam attack ends and the backlog is cleared, the transaction will confirm.
|
|
|
|
|
Show Posts
