Search content
Sort by
Showing 20 of 113 results by 73blazer
Re: The Black Pill hashrate enlarger Tool v1.0 for NVIDIA LHR cards
SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS ! SCAM AND VIRUS !
Re: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
The new beta version is ready. It is mostly a bugfix release, the more significant upgrades are coming next month. You can download PhoenixMiner 6.3b from here:
PhoenixMiner_6.3b_Windows.zip
PhoenixMiner_6.3b_Linux.tar.gz
The new features in this release are:
Known issues (driver incompatibilities, etc.) and workarounds:
If you are using Linux drivers 21.40.1 with Radeon VII cards, you need to add the option -fpwm 1 in order to have proper fan control.
AMD Linux drivers 21.40.1 has finally removed the requirement of PCIe atomics but there are problems when you try to mix Polaris (RX4x0/5x0) cards and Vega or newer cards on the same rig.
Some Nvidia cards will report a lot of stale shares under Windows 11. Using the same driver version under Windows 10 resolves the issue.[/list][/list]
PhoenixMiner_6.3b_Windows.zip
PhoenixMiner_6.3b_Linux.tar.gz
The new features in this release are:
- Full LHR disable mode -lhrdis <n> 1 - yes (default), 0 - no
- RTX 3060 LHR ~ 50 MH/s
- RTX 3060 Ti LHR ~ 60 MH/s
- RTX 3070 LHR ~ 60 MH/s
- RTX 3070 Ti LHR ~ 81 MH/s
- RTX 3080 10GB LHR ~ 98 MH/s
- RTX 3080 Ti LHR ~ 120 MH/s
- Dual mining TON
- Fixed an issue with expired SSL certificate that led to "certificate verify failed" errors when connecting to some pools (notably Ethermine) when using SSL connections
- Show the GPU vendor name in the list of GPUs to make it easier to identify the GPUs
- Added support for the latest AMD Linux drivers 21.40.1. There are some bugs in these drivers, particularly the clocks and voltages can't be set properly with older
cards (RX4x0/RX5x0/Vega/RadeonVII) - Validated support for the latest AMD Windows drivers up to 21.11.2
- Fixed issues with AMD RX6700XT cards with the latest AMD and Linux drivers
- Fixed issues with AMD Vega and Radeon VII cards on latest Windows and Linux drivers
- Fixed crash with very old Nvidia drivers (3xx.x)
- Other fixes and small improvements
Known issues (driver incompatibilities, etc.) and workarounds:
If you are using Linux drivers 21.40.1 with Radeon VII cards, you need to add the option -fpwm 1 in order to have proper fan control.
AMD Linux drivers 21.40.1 has finally removed the requirement of PCIe atomics but there are problems when you try to mix Polaris (RX4x0/5x0) cards and Vega or newer cards on the same rig.
Some Nvidia cards will report a lot of stale shares under Windows 11. Using the same driver version under Windows 10 resolves the issue.[/list][/list]
Re: What do you want to but with BTC? Or for what to accept it as payment?
I get mad when people say we take bitcoin, only to find you have to use some preferred service, have a wallet with them, in order to make a payment, I don't know of too many places that will just say send some coins to X btc address. They all want you to sign up with their partner vendor, buy coins from there (most of those vendors won't let you send your coins to them either, you can only populate your wallet with them if you buy coins from their platform), then spend the coins from an account with coins but not a real btc transaction!
Yeah, no thanks. I'd use BTC as a means of payment for more expensive items if people would take it by just saying send coins here, like the scam emails saying I've watched some bad porn always say.
Yeah, no thanks. I'd use BTC as a means of payment for more expensive items if people would take it by just saying send coins here, like the scam emails saying I've watched some bad porn always say.
Ahh, ok. Makes sense. I used to only back it up manually after I've made some transaction (I only do a few transaction/year), but recently I put in an offsite backup job and it's backing up stuff that has changed every hour now and I see it change in the log and get backed up several times/day, was just wondering why.
Under bitcoin core (currently 0.20.1) full node full chain I'm just curious why wallet.dat file keeps changing a few times day even though I've made no transactions??? I understand and expect stuff in blocks dir and chainstate dir to change but why is wallet.dat file changing?
That sounds like a DOS attack, to be honest. I usually see weeks pass without a single connection from an actual SPV client, though there are bunch of shitty spy things that pretend to be them. It absolutely shouldn't be making remotely that kind of difference.
uh, also, 125 is the maximum connections.
The only issue it exposes you to are DOS attacks and any bugs in that functionality... though bugs seem fairly unlikely at that point. The DOS attack issues have been exploited in the wild, so for a rarely used and not very useful functionality.
I had upped the max with -maxconnections=500 a while back. All I can say is I have the upload bandwidth to deal with it and it was managed via myfirewall as low priority so any other traffic would supersede it and choke it off. So I guess I never noticed how much it was using on a constant basis, only every time I looked it was 120+ connections inbound and serving 10's of gb/day.
I cut off mainchain, it's now at 61 inbound after 1.5days in that mode and has served 24GB in that time. Slightly down but seems to be going up over time.
DoS attacks suck. But does seem like it's rather pointless in this context. I dunno, I leave it off for now. Sounds like SPV clients are on the way out anyway in favor of other lite methods, might as well show them the door. It's not Gov't, it's just my vote with my node.
Are there any SPV wallet which still use bloom filter nowadays?
Source : https://eprint.iacr.org/2014/763.pdf
Apparently there are, because if I turn them on my "inbound" connections go from 20-50 to 120-200 . And over a typical days time I would serve out 30-40GB where in the last 24hrs on 0.19.1 with them off i've served 8gb.
Correct me if I'm wrong, but after reading some material on it, the privacy risk seems to be the clients and not mine, the risk is if I was running a node with intent to do something with that info the SPV clients expose to me.
I've just read certain things and opinions, like:
- your not a full node unless your offering bloom filters.
- CUtting it off is playing government it's an allowed bip and not offering it is attempting to encourage others behavior, aka, trying to tell them what to do
- your node will be overrun with DOS attacks
stuff like that. Surely, it's up to me. Was just trying to edumacate myself to the best of my ability to decide. I appreciate the education and responses!
I've been running core for years on mainchain and testnet.
I just upgraded from 18 to 0.19.1. I noticed my inbound connections were far lower than normal. Usually was in the hundreds and was just in the 10-20 range after 15 minutes back up, and I noticed an inordinate number of peers connecting and going immediately away.
I never really minded it before, I did had to set my firewall's bandwidth manager to make that traffic low priority because it would use alot of my upload bandwidth and cause other things I really need to be slow, which worked just fine for years, that's what the bandwidth manger feature in my firewall is for, let it use it when nothing else wants to, when something important comes along, choke off the bitcoin node traffic. Worked fine for years.
So I read NODE_BLOOM is off by default now which is why my connection counts are down. I'm fairly technical generally but not really up on the super technical details of bitcoin clients. From reading the release notes the developers kinda make out NODE_BLOOM as evil. Apparently this was accounting for a large percentage of my node's traffic, so are these evil? Are these just other peers taking more than their giving? Should I turn it back on? I turned it back on for testnet. What's the general consensus on nodes who allow or don't allow NODE_BLOOM?
I just upgraded from 18 to 0.19.1. I noticed my inbound connections were far lower than normal. Usually was in the hundreds and was just in the 10-20 range after 15 minutes back up, and I noticed an inordinate number of peers connecting and going immediately away.
I never really minded it before, I did had to set my firewall's bandwidth manager to make that traffic low priority because it would use alot of my upload bandwidth and cause other things I really need to be slow, which worked just fine for years, that's what the bandwidth manger feature in my firewall is for, let it use it when nothing else wants to, when something important comes along, choke off the bitcoin node traffic. Worked fine for years.
So I read NODE_BLOOM is off by default now which is why my connection counts are down. I'm fairly technical generally but not really up on the super technical details of bitcoin clients. From reading the release notes the developers kinda make out NODE_BLOOM as evil. Apparently this was accounting for a large percentage of my node's traffic, so are these evil? Are these just other peers taking more than their giving? Should I turn it back on? I turned it back on for testnet. What's the general consensus on nodes who allow or don't allow NODE_BLOOM?
Re: [ANN] [NWC] Newscrypto.io – All About Crypto In One Place [Crypto Trading Edge]
I think KuCoin is the newexchange. Since your coin is placed on 5 exchange, trader can easily convert to their desired coin from NWC. Great
Well..I finally figured it out with the help of on irc bitcion chat.
He mentioned it could be some firewall somewhere that is matching something in that block to an antivirus signature
He was right, I turned off my sonicwall gateway antivirus and it started moving and fully sync'd right up.
So...an oddball one, hope it helps someone in the future. I turned back on my gateway antivirus after it sync'd. I'll report to sonicwall a false positive, but they likely won't do much about it
He mentioned it could be some firewall somewhere that is matching something in that block to an antivirus signature
He was right, I turned off my sonicwall gateway antivirus and it started moving and fully sync'd right up.
So...an oddball one, hope it helps someone in the future. I turned back on my gateway antivirus after it sync'd. I'll report to sonicwall a false positive, but they likely won't do much about it
I turned on some higher level debugging, this is what I get:
Not much there, request the next block, and socket recv error. I can clear the whole testnete data dir and request next block works fine until 1354780...stops cold there. pulling my hair out!!! ANyone...suggestions........
Quote
2018-07-24 23:27:47 sending version (102 bytes) peer=13
2018-07-24 23:27:47 send version message: version 70015, blocks=1354779, us=[::]:0, peer=13
2018-07-24 23:27:47 sending verack (0 bytes) peer=13
2018-07-24 23:27:47 receive version message: /bcoin:v1.0.0-pre/: version 70015, blocks=1355070, us=71.13.92.62:18333, peer=13
2018-07-24 23:27:47 received: verack (0 bytes) peer=13
2018-07-24 23:27:47 sending sendheaders (0 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending ping (8 bytes) peer=13
2018-07-24 23:27:47 initial getheaders (1355313) to peer=13 (startheight:1355070)
2018-07-24 23:27:47 sending getheaders (1061 bytes) peer=13
2018-07-24 23:27:47 sending feefilter (8 bytes) peer=13
2018-07-24 23:27:47 received: addr (31 bytes) peer=13
2018-07-24 23:27:47 received: sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 received: getblocks (1061 bytes) peer=13
2018-07-24 23:27:47 getblocks -1 to end limit 500 from peer=13
2018-07-24 23:27:47 received: pong (8 bytes) peer=13
2018-07-24 23:27:47 received: headers (1783 bytes) peer=13
2018-07-24 23:27:47 Requesting block 000000000000000f49b212a0150642ebd2204b8b3d2eaa0dd58f83a0ab4e2ce2 (1354780) peer=13
2018-07-24 23:27:47 sending getdata (37 bytes) peer=13
2018-07-24 23:27:47 connection to 123.115.67.133:18333 timeout
2018-07-24 23:27:47 socket recv error Connection reset by peer (104)
2018-07-24 23:27:47 disconnecting peer=13
2018-07-24 23:27:47 Cleared nodestate for peer=13
2018-07-24 23:27:47 send version message: version 70015, blocks=1354779, us=[::]:0, peer=13
2018-07-24 23:27:47 sending verack (0 bytes) peer=13
2018-07-24 23:27:47 receive version message: /bcoin:v1.0.0-pre/: version 70015, blocks=1355070, us=71.13.92.62:18333, peer=13
2018-07-24 23:27:47 received: verack (0 bytes) peer=13
2018-07-24 23:27:47 sending sendheaders (0 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending ping (8 bytes) peer=13
2018-07-24 23:27:47 initial getheaders (1355313) to peer=13 (startheight:1355070)
2018-07-24 23:27:47 sending getheaders (1061 bytes) peer=13
2018-07-24 23:27:47 sending feefilter (8 bytes) peer=13
2018-07-24 23:27:47 received: addr (31 bytes) peer=13
2018-07-24 23:27:47 received: sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 received: getblocks (1061 bytes) peer=13
2018-07-24 23:27:47 getblocks -1 to end limit 500 from peer=13
2018-07-24 23:27:47 received: pong (8 bytes) peer=13
2018-07-24 23:27:47 received: headers (1783 bytes) peer=13
2018-07-24 23:27:47 Requesting block 000000000000000f49b212a0150642ebd2204b8b3d2eaa0dd58f83a0ab4e2ce2 (1354780) peer=13
2018-07-24 23:27:47 sending getdata (37 bytes) peer=13
2018-07-24 23:27:47 connection to 123.115.67.133:18333 timeout
2018-07-24 23:27:47 socket recv error Connection reset by peer (104)
2018-07-24 23:27:47 disconnecting peer=13
2018-07-24 23:27:47 Cleared nodestate for peer=13
Not much there, request the next block, and socket recv error. I can clear the whole testnete data dir and request next block works fine until 1354780...stops cold there. pulling my hair out!!! ANyone...suggestions........
Alright, what gives. This is driving me nuts.
I tried
reindex-chainstate - again stop at block 1354779
reindex - again stop at block 1354779
removing blocks and chainstate dirs - again stop at block 1354779
removing the entire data dir and starting from scratch - again stop at block 1354779
WTF?!?!?!?!?!?!
I tried
reindex-chainstate - again stop at block 1354779
reindex - again stop at block 1354779
removing blocks and chainstate dirs - again stop at block 1354779
removing the entire data dir and starting from scratch - again stop at block 1354779
WTF?!?!?!?!?!?!
Re: Bitcoin core on testnet outbounds get kicked off, won't sync
It did manage to get back to 1354779 but it stops there and eventually all my outbounds disappear/disconnect after a while and nothing ever downloads past this block.
The blockhash matches that from blockchain.info for that testnet block, why's it having issues getting the next block from the network to get back in sync?
Where should I go with this?
The blockhash matches that from blockchain.info for that testnet block, why's it having issues getting the next block from the network to get back in sync?
Where should I go with this?
Re: Bitcoin core on testnet outbounds get kicked off, won't sync
Well, that ran up to block 1354775, 4 blocks before where it was stuck before.
all my outbounds then issued me socket recv error Connection reset by peer and it's stuck sitting there again, makes a new outbound immediately gets a socket recv error Connection reset by peer back.
What's the next move? I'm tempted to remove a few blocks from the blocks dir but that's not as simple as it used to be 5 years ago the last time I had something go wrong with a core instance.
all my outbounds then issued me socket recv error Connection reset by peer and it's stuck sitting there again, makes a new outbound immediately gets a socket recv error Connection reset by peer back.
What's the next move? I'm tempted to remove a few blocks from the blocks dir but that's not as simple as it used to be 5 years ago the last time I had something go wrong with a core instance.
Re: Bitcoin core on testnet outbounds get kicked off, won't sync
I restarted with a reindex-chainstate.
It's taking it's time, but at least the outbound connections ran up to 8 and are holding at 8 while it does it's re-index.
We'll see if it holds when it gets to current.....
It's taking it's time, but at least the outbound connections ran up to 8 and are holding at 8 while it does it's re-index.
We'll see if it holds when it gets to current.....
I've got a core full node on mainnet and also on testnet running, both for years.
Currently on ubuntu with core 0.16.0
On saturday, my testnet node outbound connections dropped to 0 and it's stuck on block 1354779.
I've made no changes to my config, firewalls, network, it happened while it was running as I always leave it up, last reboot was weeks ago.
I see in the debug log it makes new outbounds but they quickly get kicked off within a few seconds to a few minutes, like my node is considered misbehaving by others or something. No blocks past the one mentioned ever get synced.
The mainnet node is running fine.
Any suggestions on what move try to remedy this? Any ideas why it happened?
Sample from log:
[
Currently on ubuntu with core 0.16.0
On saturday, my testnet node outbound connections dropped to 0 and it's stuck on block 1354779.
I've made no changes to my config, firewalls, network, it happened while it was running as I always leave it up, last reboot was weeks ago.
I see in the debug log it makes new outbounds but they quickly get kicked off within a few seconds to a few minutes, like my node is considered misbehaving by others or something. No blocks past the one mentioned ever get synced.
The mainnet node is running fine.
Any suggestions on what move try to remedy this? Any ideas why it happened?
Sample from log:
[
Quote
2018-07-21 16:13:30 GUI: Platform customization: "other"
2018-07-21 16:13:30 GUI: PaymentServer::LoadRootCAs: Loaded 146 root certificates
2018-07-21 16:13:31 New outbound peer connected: version: 70015, blocks=1354840, peer=0
2018-07-21 16:13:31 socket recv error Connection reset by peer (104)
2018-07-21 16:13:36 Imported mempool transactions from disk: 18657 succeeded, 0 failed, 0 expired, 0 already there
2018-07-21 16:13:37 connect() to [2001:0:9d38:90d7:433:113d:355b:3ed4]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:38 connect() to [2001:0:9d38:78cf:3045:4a12:ed3a:4b8b]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:39 New outbound peer connected: version: 70015, blocks=1354840, peer=4
2018-07-21 16:13:40 connect() to [2001:0:9d38:78cf:7e:9a64:4e77:6860]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:40 socket recv error Connection reset by peer (104)
2018-07-21 16:13:41 71 addresses found from DNS seeds
2018-07-21 16:13:41 dnsseed thread exit
2018-07-21 16:13:56 New outbound peer connected: version: 70015, blocks=1354840, peer=7
2018-07-21 16:13:56 connect() to [2001:0:9d38:6ab8:1c98:3aee:89e0:f3d8]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:57 New outbound peer connected: version: 70015, blocks=1354840, peer=8
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 connect() to [2001:470:a:c13::2]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:58 connect() to [2600:3c01::f03c:91ff:fe2d:799a]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:02 New outbound peer connected: version: 70015, blocks=1354840, peer=9
2018-07-21 16:14:04 socket recv error Connection reset by peer (104)
2018-07-21 16:14:09 New outbound peer connected: version: 70015, blocks=1354840, peer=10
2018-07-21 16:14:10 connect() to [2001:0:9d38:90d7:8bc:1e0b:b275:ab14]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:10 socket recv error Connection reset by peer (104)
2018-07-21 16:14:16 New outbound peer connected: version: 70014, blocks=1354840, peer=11
2018-07-21 16:14:16 connect() to [2001:41d0:800:664::]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:17 New outbound peer connected: version: 70015, blocks=1354840, peer=12
2018-07-21 16:13:30 GUI: PaymentServer::LoadRootCAs: Loaded 146 root certificates
2018-07-21 16:13:31 New outbound peer connected: version: 70015, blocks=1354840, peer=0
2018-07-21 16:13:31 socket recv error Connection reset by peer (104)
2018-07-21 16:13:36 Imported mempool transactions from disk: 18657 succeeded, 0 failed, 0 expired, 0 already there
2018-07-21 16:13:37 connect() to [2001:0:9d38:90d7:433:113d:355b:3ed4]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:38 connect() to [2001:0:9d38:78cf:3045:4a12:ed3a:4b8b]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:39 New outbound peer connected: version: 70015, blocks=1354840, peer=4
2018-07-21 16:13:40 connect() to [2001:0:9d38:78cf:7e:9a64:4e77:6860]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:40 socket recv error Connection reset by peer (104)
2018-07-21 16:13:41 71 addresses found from DNS seeds
2018-07-21 16:13:41 dnsseed thread exit
2018-07-21 16:13:56 New outbound peer connected: version: 70015, blocks=1354840, peer=7
2018-07-21 16:13:56 connect() to [2001:0:9d38:6ab8:1c98:3aee:89e0:f3d8]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:57 New outbound peer connected: version: 70015, blocks=1354840, peer=8
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 connect() to [2001:470:a:c13::2]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:58 connect() to [2600:3c01::f03c:91ff:fe2d:799a]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:02 New outbound peer connected: version: 70015, blocks=1354840, peer=9
2018-07-21 16:14:04 socket recv error Connection reset by peer (104)
2018-07-21 16:14:09 New outbound peer connected: version: 70015, blocks=1354840, peer=10
2018-07-21 16:14:10 connect() to [2001:0:9d38:90d7:8bc:1e0b:b275:ab14]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:10 socket recv error Connection reset by peer (104)
2018-07-21 16:14:16 New outbound peer connected: version: 70014, blocks=1354840, peer=11
2018-07-21 16:14:16 connect() to [2001:41d0:800:664::]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:17 New outbound peer connected: version: 70015, blocks=1354840, peer=12
On the website now is no more E10, but now they have E9.3 (16t) and E9.2(12t) both say they are their (sudo)10nm dw1228 (same used in E10.1) chip and gives 110w/th
They're all over the board with this stuff. What happened to the E10?? The E9++??? Support shows 9.2 firmware, but no 9.3 firmware. 9.3 is listed at $950 and 9.2 is listed at $1150. WHy would you price the higher th unit less??? Does 9.3 even exist?
I just don't really trust them. The power has always been more than advertised and the e10 looks like nowhere near the 90w/th they said. the e9+ consumers more than advertised although not terribly out of range. Support is non-existent, just look at their very first product the E9, those people who bought those totally got screwed, they basically never even supported them even when they were only weeks old.
Why are they making so many different products??? They could barely support it when they had 1 or 2 and I'm just talking firmware updates, hardware support never really seems to have existed. Now they have what...
What the heck. Are 9.3 and 9.2 just attempts to use their underperforming dw1228 chips they were putting in the e10??
These products once you have them...if you can get them...if you want them... is they are what they are. If they work, great, if not, your SOL. I've got 3 e9+ , 2 I bought from them directly though a very convoluted process mostly based on prayers and hope....but I did get them and those 2 work perfect since last fall since I got them aside from the 130w/th, another I got off ebay and it worked for a few weeks and 2 boards of the 3 went belly up...but I think whoever had this machine beat the crap out of it, it looked like it mined in an actual dirt mining pit it was so dirty and caked up.
I had high hopes they would have some integrity behind thier company, especially since they seem to have existed making other electronic communication hardware prior to going into the mining business. But...that hope has all been lost.
They're all over the board with this stuff. What happened to the E10?? The E9++??? Support shows 9.2 firmware, but no 9.3 firmware. 9.3 is listed at $950 and 9.2 is listed at $1150. WHy would you price the higher th unit less?
?? Does 9.3 even exist?I just don't really trust them. The power has always been more than advertised and the e10 looks like nowhere near the 90w/th they said. the e9+ consumers more than advertised although not terribly out of range. Support is non-existent, just look at their very first product the E9, those people who bought those totally got screwed, they basically never even supported them even when they were only weeks old.
Why are they making so many different products??? They could barely support it when they had 1 or 2 and I'm just talking firmware updates, hardware support never really seems to have existed. Now they have what...
- e9 -- basically while still less than a year old, they say too old no support not even if you want to buy parts
- e9+ -- seems to have been their most stable product although not without issues... lots of reports of bad boards and near zero support, I've not heard of one story where someone sent their broke machine in under warranty and it was actually fixed
- e9++ -- not sure if these ever existed but they were for sale for a while, I guess
- e10 -- advertised but I think never existed, I think just renamed e10.1
- e10.1 -- power seems to have been way off, based on website news they either didn't deliver alot of them or something went wrong with alot of them, they are offering some rebate to people but it's unclear what it's for
- e10.2 -- never seems to have existed, but was shown in chiense version of website for sale for a while
- e9.3 -- http://miner.ebang.com.cn/goods-9.html
- e9.2 -- http://miner.ebang.com.cn/goods-5.html
What the heck. Are 9.3 and 9.2 just attempts to use their underperforming dw1228 chips they were putting in the e10??
These products once you have them...if you can get them...if you want them... is they are what they are. If they work, great, if not, your SOL. I've got 3 e9+ , 2 I bought from them directly though a very convoluted process mostly based on prayers and hope....but I did get them and those 2 work perfect since last fall since I got them aside from the 130w/th, another I got off ebay and it worked for a few weeks and 2 boards of the 3 went belly up...but I think whoever had this machine beat the crap out of it, it looked like it mined in an actual dirt mining pit it was so dirty and caked up.
I had high hopes they would have some integrity behind thier company, especially since they seem to have existed making other electronic communication hardware prior to going into the mining business. But...that hope has all been lost.
Re: My bitcoin has been stuck for a long time with no confirmation
1. I know that transaction can't be canceled or removed
2. When I send transaction of 0,5 btc it was not added to blockchain, so just my core wallet show that it was send. So this trasaction wa not confirmed by any miners.
3. To take this coins back to the balance of bitcoin core I remove wallet.dat and restart my bitcoin core. Bitcoin core reated new wallet.dat and I added private key from previous bitcoin wallet.
4. But when integration was dane, bitcoin core was send this transaction once more but before this transaction core automatically send 0,12 btc to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE, which I do not know (I or somebody else never use this address). Maybe this address is the new addres of my bitcoin core and wallet made this transaction to confirm the low fee transaction.
5. I know that these transactions is already confirmed
6. The question is what is this addres? Why bitcoin core made this transaction AUTOMATICALLY to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE? And how to take my 0,12 btc back, if it possible?
Well, the transaction where you sent 0.5btc to 196y4iA7kZHEHVY9NmZqtTRbD76WWV43Cf was confirmed. In that same transaction 0.124 went to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE . Internally core has a bunch of addresses it uses to send residual balances to, when you send it's actually picking various transactions that were sent to you and they have to add up to the amount your sending elsewhere, or greater, the "greater" part is what gets sent back to your own internal addresses. .... anything in those will show up in your balance however. (you can see this in core if you choose coin control when sending) .
My guess is it's one of those if you didn't explicitly send to that address. When you made a new wallet, you didn't import all the keys, is my guess. Do you have your old wallet.dat? Did you back it up immediately before making a new wallet.dat and importing old keys, ie, did you import ALL the keys from your old wallet, there's many more than just keys for receiving addresses that show up in core. YOu can view all of them in the console or dump them all from the console as well. If your sure it's not showing in your final balance, it's in the old wallet.dat, you need to export ALL the keys from there. A simple test would be to just put your old wallet.dat back in place (moving your current one to a safe name/place) and restart core. you should see your 0.124 then. Then export ALL your keys, switch your wallet.dat's again and import them into your new wallet.
Re: My bitcoin has been stuck for a long time with no confirmation
I have some problem with removing the bitcoin transaction. Maybe somebody can help me. I used bitoin core and some days ago. So I remove my wallet.dat file, restart bitcoin core and insert a private key from the previous. So bitcoin core made this transaction once more but before this transaction bitcoin core made another transaction to the bitcoin address, which I do not have.
eb90ebe8d36c6a2fe2080f3a05662dc9cb8cf50a0fec4e8dc61ee3a76c3ea82a
So the question is what is this address and how to recieve my bitcoins back.
eb90ebe8d36c6a2fe2080f3a05662dc9cb8cf50a0fec4e8dc61ee3a76c3ea82a
So the question is what is this address and how to recieve my bitcoins back.
You can't undo a transaction simply by re-initializing your wallet. Once the transaction was confirmed in the blockcahin, that's it, there is no going back, no undo, no option to "remove" a transaction. Any core installed on any computer anywhere in the world with any wallet.dat will see this transaction. The blockchain is unalterable once it has confirmed, by design.
So, unless you have the private keys to 196y4iA7kZHEHVY9NmZqtTRbD76WWV43Cf or 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE , you cannot have these coins.
Who made this transaction? What was the intent? Where did either of the addresses come from (who has the private keys for them)? Were they addresses from some other wallet you have you were trying to move coins to?
The bottom line remains though, unless you have the private keys to those addresses, you cannot have the coins.
⭐ Merited by DannyHamilton (2)
It's called Bitcoin Credit. It allows you to spend an amount you don't have up to (the number of years that address has been in existence X upper most amount of BTC it once had) up to a maximum of 1 BTC total .
Examples:
I once had 0.25 BTC in an address that has existed for 1/2 year. I'd be able to spend from that same address on Bitcoin Credit of 0.125 BTC
I once had 2.45 BTC in an address tha has existed for 3 days. I'd be able to spend from that same address on Bitcoin Credit 0.02013 BTC
I once had 1.24 BTC in an address that has existed for 3.4 years. I'd be able to spend from that same address on Bitcoin Credit 1 BTC
You have 1 year to pay it back + a fixed 20%, or the bitcoin Men In Black, or Putin, will come for you. The 20%, goes to the core developers to spend on upcoming features. Or beer.
I'm kidding, of course.
It's just a double spend or an attempt at a double spend. Most times this is not someone trying to spend coins twice in a malicious way. Most times, but not always there are many reasons it could be..but most times it is someone who submitted a transaction with too low of fee and re-submitted it with a higher fee. Until his 1st low fee trans is dropped, it would show a negative balance. One one would ever confirm. But it takes 3-7 days or more depending on the software that is submitted it, to be dropped.
Examples:
I once had 0.25 BTC in an address that has existed for 1/2 year. I'd be able to spend from that same address on Bitcoin Credit of 0.125 BTC
I once had 2.45 BTC in an address tha has existed for 3 days. I'd be able to spend from that same address on Bitcoin Credit 0.02013 BTC
I once had 1.24 BTC in an address that has existed for 3.4 years. I'd be able to spend from that same address on Bitcoin Credit 1 BTC
You have 1 year to pay it back + a fixed 20%, or the bitcoin Men In Black, or Putin, will come for you.
The 20%, goes to the core developers to spend on upcoming features. Or beer. I'm kidding, of course.
It's just a double spend or an attempt at a double spend. Most times this is not someone trying to spend coins twice in a malicious way. Most times, but not always there are many reasons it could be..but most times it is someone who submitted a transaction with too low of fee and re-submitted it with a higher fee. Until his 1st low fee trans is dropped, it would show a negative balance. One one would ever confirm. But it takes 3-7 days or more depending on the software that is submitted it, to be dropped.