Weird, I've restarted it a few times, perhaps another node that I have whitelisted elsewhere is submitting the transaction immediately once I restart. I'll try isolating it from the network and doing it.
If you run beforehand and it tells you that the transaction is not in the mempool but you still can't abandon it, then there must be something else that is blocking it from being abandoned, but I don't know what that could be. Well it is in the mempool and it's 0.13.2 and restarting it doesn't remove it from the mempool... Hmm it could be because I getblocktemplates regularly from the bitcoind... or not :s |
|
|
|
That's interesting in itself. What else could possibly be blocking it? bitcoin-cli abandontransaction XX
error code: -5
error message:
Transaction not eligible for abandonment
Anything that would cause this function: https://github.com/bitcoin/bitcoin/blob/02464da5e4aa8c19d4fff3859dcdee822e2af78c/src/wallet/wallet.cpp#L1052 to return false. So it seems the only criteria are that the transaction is not in the mempool and it is not confirmed. So clearing the mempool by restarting the node should work (if you are using any version greater than 0.13.2 i.e. a build of master, then you need to delete mempool.dat in the datadir). Weird, I've restarted it a few times, perhaps another node that I have whitelisted elsewhere is submitting the transaction immediately once I restart. I'll try isolating it from the network and doing it. |
|
|
|
Abandon transaction is greyed out so presumably it's subject to the same limitations as zap.
No, that means that something else is blocking it from being abandoned. I'm pretty sure it still works in pruned mode as I'm pretty sure I did it before. That's interesting in itself. What else could possibly be blocking it? bitcoin-cli abandontransaction XX
error code: -5
error message:
Transaction not eligible for abandonment
|
|
|
|
Right click the transaction and choose "Abandon transaction" or use the abandontransaction command in the rpc console.
Or you can use something like pywallet and remove the transaction from your wallet file manually.
Abandon transaction is greyed out so presumably it's subject to the same limitations as zap. |
|
|
|
|
Since -zapwallettxes implies -rescan, it means its use is effectively mutually exclusive of using pruned mode. Does anyone have any suggestions for a workaround without redownloading the whole blockchain again?
|
|
|
|
|
You could try the bfgminer support thread for an official response, but I actually hope it's the same there to prevent more futile exercises and not encourage pointless CPU use, PC hijacking and botnet creation.
|
|
|
|
Roughly 25TH since late November... some equipment lit on fire, bought more equipment... still at 25TH
Good luck to you too! Give me your Friday Blessing as well, oh my great Guru! .de node lottery goes on  And good luck to you! |
|
|
|
Just hooked up my Antminer S3 to this pool. Wish me luck...
You got it. Good luck! I am still reading this thread but what was the slowest miner to find a block ? I see there was a few S7's in the last year. Any S5's? S3's ? USB Miners ? S3 has been the smallest so far. |
|
|
|
Just hooked up my Antminer S3 to this pool. Wish me luck...
You got it. Good luck! |
|
|
|
I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please cite a source for this.
No one said that, did they? On the other hand, "minor" changes in the BU code even before their hard fork activation have already led to invalid block generation. |
|
|
|
|
There is no tutorial because there is no software that does what you want. I consciously removed the ability to mine with cpu and gpu from cgminer years ago to prevent people futilely attempting to do so, and in the meantime the communication protocol for mining was completely revamped. Thus there is no current mining software that both mines on cpu and speaks the current mining protocol.
|
|
|
|
|
Enough replies. I'm locking the thread to prevent it being used as a sigspam dumping ground.
|
|
|
|
|
Thread hijacked by a sigspammer asking different questions. Locking thread after deleting his posts. OP you can ask for your thread to be unlocked if you like but I don't think there's much more to say here.
|
|
|
|
Segwit IS a technological advancement, but make no mistake, any arguments about complexity being the issue versus the "simplicity" of just increasing the blocksize are a red herring and diverting attention away for why the miners are reluctant to move forwards with it. I'm sure that you are a solid developer since you run a mining pool. Are you 100% confident that changing 4743 lines of code deep in the Bitcoin codebase won't have any issues? And what about wallet and 3rd party software? When you add it all up, we're looking at tens of thousands of lines of code changes, which guarantees roughly 150-500 bugs (industry average) in all of this software, of which 2-5 are potentially catastrophic... A hard fork to 2MB would involve one line of code change and some late-night sweating and swearing for a week  No I can't be 100% confident by myself, but luckily we have far more developers who have been doing almost a year of actual hard testing on testnet validating its stability. On the other hand you're also grossly exaggerating the simplicity of a hard fork by not describing the work required to make that one line of change work (it's also more than one line but that's irrelevant.) |
|
|
|
Thanks - Hopefully it's all working correctly. The Discarded seems high compared to the accepted but maybe that's just how it is now that the difficulty is 'higher', or I could be wrong and have no idea.  Discarded is meaningless. You can ignore it. |
|
|
|
Can someone help me calculate transaction fees?
Im still learning how to send/receive and I want to make sure
my BTC get to where theyre going safely. Toss me an IM.
If you are using the bitcoin core client it will estimate for you. If not, use this site to get an idea of what fee to use: https://bitcoinfees.21.co/ |
|
|
|
These three posts combined subtly actually have all the issues as to why miners haven't started signalling support and give the best summary for why we're currently in a stalemate. A lot of the problems seem to stem from miscommunication and lack of communication between developers and miners. It seems that some miners have taken a grudge against the developers (all of them in general) for not consulting them when devising scaling solutions.
Not quite true, they have been consulted at various times, and ran their own meetings, and most of the time were unconvinced about segwit and kept pushing for bigger blocks. Miners agree on enabling segwit and mostly malleability fix IF the Core client also remove the the current block size limit.
They aren't enabling it because segwit leaves the block size limit in the hand of the devs of Core, and miners don't trust them and their promises anymore. While some pools were willing to accept segwit straight up, this was the compromise position a lot more of them adopted - they would be willing to adopt segwit if the promise of bigger blocks was still kept. The fact that there is actually no firm bigger block hard fork on the definite roadmap is why the miners are still sitting on segwit adoption. As for what the miners objection to segwit is... Or maybe its because the developers keep trying to find ways to not share any additional revenue with the miners while increasing the data storage the pools will need and pitting conventional pools against SPV-(EMPTY BLOCK)-miners in china for conformations/propagation time.
Not many people have explicitly said out loud what the miners' real objection is and basically the fact is that transaction volume can increase without a proportionate increase in reward for miners. They've invested hundreds of millions of dollars in hardware to secure the system for us on the basis of relatively predictable rewards as compensation and segwit has the potential to dilute this - lightning network will amplify this issue and segwit makes LN easier. The actual magnitude of loss of reward is greatly exaggerated by many, and adding conspiracy theories of redirecting rewards to blockstream are not helping the situation. Additionally, doubling the block size doesn't mean double the transaction fees since there is less competition for fees with more space available. Segwit IS a technological advancement, but make no mistake, any arguments about complexity being the issue versus the "simplicity" of just increasing the blocksize are a red herring and diverting attention away for why the miners are reluctant to move forwards with it. I've voted for it, but my pool is less than 0.1% of the network, and I believe the network needs a multi-pronged approach to increasing bitcoin's ability to process more transactions, and that transaction volume will more than offset any theoretical loss of reward from segwit. However that's not what the large pools believe. Campaigning by vocal but powerful mining pools is largely preventing them getting on board. |
|
|
|
BU is rapidly growing in popularity and it's exceeding support for SegWit, so it looks like BU is winning, not Core. So, sad for you.
Not sure where you come to that conclusion. More than 50% of regular nodes are signalling support for segwit which is already a majority of sorts, far more than are signalling support for BU, and there are 5x as many miners signalling support for segwit than BU. Neither has the majority required to create the dominant chain since they both fall far short of their mining node requirements for activation, but on those numbers there is no sign whatsoever that BU is "exceeding support for SegWit" and "winning" as you claim. The only thing BU seems to be exceeding support for is the number of new posts on btctalk, though most of them are coming from the same forum members (EDIT: Most of whom I've set to ignore since they don't use sane arguments and are mostly trolls). |
|
|
|
anyway I can configure so that my mining starts at a particular diff? I have a U3 and it takes forever each time it restarts for difficulty to drop from 4K to 175 so that I can generate shares that actually get accepted. until it drops to 175 all my shares are discarded? if no way, then I have to switch back to antpool solo mining since, it seems to be recycling often recently and with 60ghs lottery you can't be also down 1 out of 3 days to boot  Shares are only cosmetic on the solo pool. It doesn't matter if you're getting them or not since they're just showing you that you're successfully mining and have no intrinsic value in solo mining. However if you are using cgminer, then solo.ckpool.org, like all ckpool based pools, supports the command line parameter that will allow you to suggest a suitable diff for your hardware to speed up the process of getting to your optimal diff. Add the following command to your cgminer parameters: |
|
|
|
|
Show Posts
