 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
|
@BABYCHAIN, can you post a timeline to the main announcement page so we can see what your plans are going forward? It doesn't have to be hard dates, but rather things you are waiting for if that is easier (waiting for 10,000 master nodes for example). Obviously keep it up to date when things change, etc. This will help those supporting this coin with an idea as to when things will happen.
Thanks!
|
|
|
|
MacOS Wallet crashing on me
I was starting up my 4th masternode this morning and after getting everything up and synced, I was restarting my wallet to re-read the masternode.conf file and allow me to start the node, but it crashes on startup.
So I fixed/rebuilt it. What I did was copy the whole directory away (to back it up), then ran the app again. This created a new empty directory. I then copied the conf and dat files back over the new install. Lastly I had to run the app with a -reindex to get everything synced. There may have been a quicker way, but this appears to have restored everything. |
|
|
|
MacOS Wallet crashing on me I was starting up my 4th masternode this morning and after getting everything up and synced, I was restarting my wallet to re-read the masternode.conf file and allow me to start the node, but it crashes on startup. Last lines in debug.log are: 2018-04-21 14:59:56 init message: Verifying blocks...
2018-04-21 14:59:56 Verifying last 100 blocks at level 4
2018-04-21 15:00:01 No coin database inconsistencies in last 101 blocks (188 transactions)
2018-04-21 15:00:01 block index 7941ms
2018-04-21 15:00:01 init message: Loading wallet...
2018-04-21 15:00:02 nFileVersion = 3009900
2018-04-21 15:00:02 Keys: 1005 plaintext, 0 encrypted, 1005 w/ metadata, 1005 total
2018-04-21 15:00:02 wallet 74ms
2018-04-21 15:00:02 UpdateTip: new best=0000000000feab7aef3cd4efb06005794342e788e72280dd01f95ca1ba87114b height=20479 log2_work=50.517107 tx=50972 date=2018-04-21 14:51:38 progress=0.999771 cache=1
Crashed thread according to osx debug window: Process: BABY-Qt [94787]
Path: /Applications/BABY-Qt.app/Contents/MacOS/BABY-Qt
Identifier: io.baby.Baby-Qt
Version: 3.0.99 (3.0.99)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: BABY-Qt [94787]
User ID: 1000001
Date/Time: 2018-04-21 10:08:18.906 -0500
OS Version: Mac OS X 10.13.2 (17C205)
Report Version: 12
Bridge OS Version: 3.0 (14Y661)
Anonymous UUID: 90872D84-924D-6D9E-F608-A1894EF5A72B
Sleep/Wake UUID: 90370E15-BE72-456C-BFC9-C343FBC124A9
Time Awake Since Boot: 5400000 seconds
Time Since Wake: 6300 seconds
System Integrity Protection: enabled
Crashed Thread: 9 QThread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Thread 9 Crashed:: QThread
0 io.baby.Baby-Qt 0x00000001081e409b 0x107fb5000 + 2289819
1 io.baby.Baby-Qt 0x00000001081bf9e0 0x107fb5000 + 2140640
2 io.baby.Baby-Qt 0x000000010815ade8 0x107fb5000 + 1727976
3 io.baby.Baby-Qt 0x0000000107fbdbf4 0x107fb5000 + 35828
4 QtCore 0x00000001098b6a31 QObject::event(QEvent*) + 769
5 QtWidgets 0x0000000108bf4ffd QApplicationPrivate::notify_helper(QObject*, QEvent*) + 269
6 QtWidgets 0x0000000108bf639a QApplication::notify(QObject*, QEvent*) + 362
7 QtCore 0x000000010988d798 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 168
8 QtCore 0x000000010988e938 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 840
9 QtCore 0x00000001098e2158 QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 72
10 QtCore 0x00000001098892be QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 398
11 QtCore 0x00000001096c8342 QThread::exec() + 114
12 QtCore 0x00000001096cc45c 0x10969f000 + 185436
13 libsystem_pthread.dylib 0x00007fff512226c1 _pthread_body + 340
14 libsystem_pthread.dylib 0x00007fff5122256d _pthread_start + 377
15 libsystem_pthread.dylib 0x00007fff51221c5d thread_start + 13
Let me know if you need more info. In the meantime, I will backup what I have and try reinstalling in case it helps. |
|
|
|
|
Anyone looking for Bitmain coupons, go ahead and PM me. I have about 9 $100 coupons and 9 $200 coupons. Just spent my $400 coupons and don't plan on buying too much more for a bit. Hate to see them go away. Free to any takers, but would prefer them to be used for miners for Kano pool.
|
|
|
|
...
Anyway, that is my experience with the 2 repair services.
My experience with the two services was a little difference. I have had 4 boards fail between 6 S9s. The first 3 were from 2 of my earlier machines and were out of warranty, so I send them to Bitmain Warranty in Colorado. Never heard much back for a couple weeks and when I eventually heard back from then (about 4 weeks total), they apologized send the boards back fixed for free. My last experience was with the new repair place in LA. Since the machine was under warranty, I had to send the whole machine. This also took a month and it wasn't until I opened a separate support ticket that magically my machine was shipped back. Both took 4 weeks, and cost nothing. I guess I can't really complain.  . On the other hand I did lose 2 months of hashing so it did cost lost revenue. |
|
|
|
So, if I understand this correctly: if I transfer my BTC's from my Kano destination wallet X to another wallet Y, and I use wallet Y to spend to BTC, I no longer have the "large amount of small transaction Satoshi's generating huge fees" issue?
Correct. Remember that the block chain is a giant accounting ledger. When you collect a bunch of small entries to create a larger one, it takes more space. The transaction fee is based on how much space it takes. If you have one large input entry, you usually get two output entries (one to your destination, one with change back to you). That is about as cheap as it gets. If you have 28 small input entries, and then the two output (unless you have no change at all, then you have one output), you end up with 10 times the number of transactions and subsequently 10 times the fee. It is the sending wallet that puts this all together. By using an exchange as the first wallet, they consolidate for you and generally charge a fixed fee rather than a per transaction type fee. |
|
|
|
It is indeed the transaction combination issue leading to high fees when using the (small amounts) of mined BTC I'm referring to.
I think I understand your workaround, although I would not know how to achieve this.
Can you please elaborate on this?
Let me try, using my approach as an example. I have my wallet at gemini.com as my payout wallet here at Kano.is. All the payments go there and collect. Once a month, when I get my hosting bill, I pay that bill (in bitcoin), transfer some to my bank account (to pay other cryto related bills) and transfer the remainder to my keepkey (hardware wallet) account. When I need to spend bitcoin, I use the hardware wallet, and because all the incoming transactions are fairly large (in a relative sense, compared to my normal spend), I pay minimal fees to spend the coin. I have tried different approaches and this one is currently working the best for me. |
|
|
|
Obelisk was sent an email about "Confirmed! We have received your coins. You will receive a second email when we verify + process the payment, and convert it to USD. This should be within 1 day. Thanks so much for your support and patience!
- Zach Herbert, VP of Operations "
But no any reply after this email.
Does anyone receive reply after received that email??
Yes, you should get a second email. They have been swamped trying to get the v1.3.0 of Sia out the door and have been slow processing the orders. You can always reach out to them and ask for your status in particular. If it is has only been a couple days, I wouldn't worry. If it is over a week, I would reach out to Zach and get an up to date status on your order. |
|
|
|
Started the program and received an error log telling me to restart the slad.
I have seen this issue encountered by others on the reddit blog about this new release.
This often happens when you close the client and immediately try to reopen it. Basically the old daemon is still running (shutting down) and you try to start the new one. This fails and tells you to restart the daemon. It sometimes takes a while to shutdown and the only way to tell is to see if siad is still running. If it is, best to probably just wait, although I have been known to kill the process if it takes too long. Doesn't seem to hurt but your mileage may vary. |
|
|
|
If you were upgrading from 1.1.1 (and not 1.2.x) then it is normal it takes a very long time (even several hours) as the client is going to re-scan the whole blockchain to find out the funds you have in the wallet
It can be much longer if you were hosting. They changed the they manage storage space in the 1.2 upgrade, so if you were hosting, I have heard of people taking 48hrs to upgrade - especially if you were using HDD, rather the SSD. Also I have found that when you shutdown the client to upgrade, it may take a few minutes for the said process to actually stop. When you try to start the new client/daemon, it will complain it is already running. In both cases, the answer is patience, although 48 hours is a lot of patience. |
|
|
|
I for one predict 12 more.  Don't go jinx'n it now with your predictions.. |
|
|
|
|
For those waiting for v1.3.0, I have a bit of an update.
The testing and fixing of problems has been ongoing with quite a few long standing bugs found. As of yesterday morning, Taek said that they had found and fixed all the bugs discovered by the group in the #contributor channel. With that he released an RC8 build for a final round of testing.
Nothing of significance has been discovered since then and I expect he will release the v1.3.0 pretty soon (just my opinion). It has been a lot longer coming but I think everyone will be surprised in the performance improvements and happy with the reduced number of problems.
|
|
|
|
Drat,
One of my hashing boards on my older of two S9's is not working. I am getting about 9T-Hash/sec on that S9.
Has anyone worked with Bitmain to get a replacement hashing board? It is out of warranty so I will have to either run at 2/3rds or try the not very happy arena of ebay if Bitmain can not get me a replacement.
I have put in a repair request asking that question of bitmain but would appreciate any knowledge of past experience others have had with them.
dzimmerm
Assuming the miners are in the US, I would use Bitmain Warranty in Colorado. They can either sell you new boards, or try to repair your old boards. I recently had three boards repaired there (was like getting a new S9 back . It wasn't the fastest service, but it was cheaper and closer than trying to deal with Bitmain directly. https://bitmainwarranty.com/ |
|
|
|
I was still in the syncing process with my slow old hard drive and had to stop then restart the client. When I was doing it the client automatically starting updating itself to v1.3.0 Everything went fine and it keep all the blocks I received previously before shutting down the client. So all is good with the update and will let you know when it has fully synced. Now I see why you would need a ssd to do this because I am on day eight now(on and off and not straight!  ).  If you didn't mistype something I would be very concerned if the client automatically updated to v1.3.0. That version is not even released yet (still at the RC stage). Also I wasn't aware the GUI client auto updated even when it is released (you can manually ask it to update and it will). I will look at the auto update stuff when I get home to my mac but your description is a little concerning. |
|
|
|
|
Once the ASICs ship, even only 1200 of them, it will increase the difficulty and be enough to push GPU miners to find a more profitable coin for them. At that point since the ASICs are homogeneous in terms of hash rate, the won't matter what that rate is (as long as it was high enough to push the GPUs out). At that point each miner will earn on average 1 / <number of miners> * block reward. Hash rate is not part of that formula. Hash rate will cause the difficulty to rise, but nothing else will change.
Later, if there is a generation 2 Obelisk, or someone else enters the Sia ASIC market, it gets interesting as the formula gets complicated and see start to see concerns about hash rate / watt, etc..
|
|
|
|
Make no release before it is ready. The RC5 candidate for Sia was posted last night on the slack contributors channel. Plan earlier this week was to release 1.3.0 on Friday if it is ready. Testing on the RC5 candidate will determine that. Testing has shown that it is not yet ready for general release. It will be a couple more days before 1.3.0 comes out. darval where did you get this information? As I mention in a the quote you used, the sia slack, the contributors channel in particular which is where taek posts the upcoming release candidates. http://siatalk.slack.comThere is currently a RC6 candidate there. Because of the scope of 1.3.0 changes, they have found quite a bit of problems and are unwilling to release it until they get them all resolved. RC6 resolves the problems they have seen to date except one (that I am aware of). Because of the instability tho, I wouldn't update to them unless you are willing to deal with some of these issues and provide feedback. If you are, please do join us and help test the upcoming release. |
|
|
|
Make no release before it is ready. The RC5 candidate for Sia was posted last night on the slack contributors channel. Plan earlier this week was to release 1.3.0 on Friday if it is ready. Testing on the RC5 candidate will determine that. Testing has shown that it is not yet ready for general release. It will be a couple more days before 1.3.0 comes out. |
|
|
|
Make no release before it is ready. The RC5 candidate for Sia was posted last night on the slack contributors channel. Plan earlier this week was to release 1.3.0 on Friday if it is ready. Testing on the RC5 candidate will determine that. |
|
|
|
|
