d5000
Legendary
Offline
Activity: 4060
Merit: 7348
Decentralization Maximalist
|
|
August 17, 2014, 05:05:21 AM |
|
Proof of burn is _not_ about burning all the coins you get. Imagine if all miners would do this in a pure PoB coin - there would be no coins left to trade, for eCommerce etc. It would be not a coin but a casino-like game as you couldn't do anything with the coin than trying to "profit". So a good PoB algorithm should not make "burn-dem-all" profitable (game theory basics). The purpose of PoB is to find an equilibrium when a significant amount of coins are burnt but not all, sufficient to make an attack expensive. Maybe 5% or 10% per month. https://en.bitcoin.it/wiki/Proof_of_burn has some thoughts on it. Now the forks are another issue, that should be resolved fast, I agree. But PoB is an completely new and experimental technology. I think the great problem of this coin is that it was added too fast to a major exchange (Bter). So there arrived people expecting to make profit, and are disappointed now. That's natural, but it doesn't mean "it's all over" now because of some forking problems and a small value. I would really like to see a development community emerge for SLM or for the PoB technology as a whole, because I think it needs to be more than a one-man project and PoB has a lot of potential. (Unfortunately I'm not a developer, so I cannot help with the code, but I can do marketing and this kind of stuff.)
|
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 05:22:37 AM |
|
The only explanation I have for these forks is that the network is still small. I have been (and will still continue) looking in the source for any "sync issues" that could be fixed.
As for the fork, expect a seed node shortly, I am almost finished.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 05:33:29 AM |
|
To sync onto the correct, longest, fork, use:
Simply start the client with '-connect=76.127.202.17 -maxconnections=1' once you are synced up, you can restart the client without those flags.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
SpeedDemon13
|
|
August 17, 2014, 08:05:04 AM Last edit: August 17, 2014, 08:37:39 AM by SpeedDemon13 |
|
To sync onto the correct, longest, fork, use:
Simply start the client with '-connect=76.127.202.17 -maxconnections=1' once you are synced up, you can restart the client without those flags.
So, will you update the OP. It still has those old addnodes. After the seed node is used, do we still have to use any addnodes after that? Have you contact the mining pools and are they finally on the right fork? What will you do in the present to prevent future forks?
|
CRYPTSY exchange: https://www.cryptsy.com/users/register?refid=9017 BURST= BURST-TE3W-CFGH-7343-6VM6R BTC=1CNsqGUR9YJNrhydQZnUPbaDv6h4uaYCHv ETH=0x144bc9fe471d3c71d8e09d58060d78661b1d4f32 SHF=0x13a0a2cb0d55eca975cf2d97015f7d580ce52d85 EXP=0xd71921dca837e415a58ca0d6dd2223cc84e0ea2f SC=6bdf9d12a983fed6723abad91a39be4f95d227f9bdb0490de3b8e5d45357f63d564638b1bd71 CLAMS=xGVTdM9EJpNBCYAjHFVxuZGcqvoL22nP6f SOIL=0x8b5c989bc931c0769a50ecaf9ffe490c67cb5911
|
|
|
rfcdejong
|
|
August 17, 2014, 10:54:00 AM |
|
To sync onto the correct, longest, fork, use:
Simply start the client with '-connect=76.127.202.17 -maxconnections=1' once you are synced up, you can restart the client without those flags.
please contact the blockexplorer and pools to update their block chains http://www.blockexperts.com/slm# has an own fork, doing only PoS it seems slimcoinpool is not running at all https://slm.blockquarry.com/ seems to be on the wrong fork, but didn't found a block since 18/7 currently on block 63179 while the blockchain i'm on is at 70337
|
|
|
|
blockexperts
|
|
August 17, 2014, 11:54:12 AM |
|
To sync onto the correct, longest, fork, use:
Simply start the client with '-connect=76.127.202.17 -maxconnections=1' once you are synced up, you can restart the client without those flags.
please contact the blockexplorer and pools to update their block chains http://www.blockexperts.com/slm# has an own fork, doing only PoS it seems slimcoinpool is not running at all https://slm.blockquarry.com/ seems to be on the wrong fork, but didn't found a block since 18/7 currently on block 63179 while the blockchain i'm on is at 70337 I am resyncing the blockchain. Keep in mind that I haven't received any donations for this coin.
|
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 11:55:32 AM |
|
I have contacted all pools, explorers, exchanges, etc related to Slimcoin regarding the fork.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 11:58:40 AM |
|
What will you do in the present to prevent future forks? The reason for this fork was purely because of a small network. When the seed node went offline, all nodes simply went onto two different forks.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
blockexperts
|
|
August 17, 2014, 12:38:39 PM |
|
To sync onto the correct, longest, fork, use:
Simply start the client with '-connect=76.127.202.17 -maxconnections=1' once you are synced up, you can restart the client without those flags.
please contact the blockexplorer and pools to update their block chains http://www.blockexperts.com/slm# has an own fork, doing only PoS it seems slimcoinpool is not running at all https://slm.blockquarry.com/ seems to be on the wrong fork, but didn't found a block since 18/7 currently on block 63179 while the blockchain i'm on is at 70337 I am resyncing the blockchain. Keep in mind that I haven't received any donations for this coin. Block Explorer is in sync.
|
|
|
|
rfcdejong
|
|
August 17, 2014, 01:33:26 PM |
|
As of today i'm getting exceptions
************************ EXCEPTION: St9bad_alloc std::bad_alloc C:\Mining\Wallets\Slimcoin\slimcoin-qt.exe in ProcessMessages()
ProcessMessage(getblocks, 901 bytes) FAILED getblocks 1 to 00000000c7308887f8db limit 66045
************************ EXCEPTION: St9bad_alloc std::bad_alloc C:\Mining\Wallets\Slimcoin\slimcoin-qt.exe in ProcessMessages()
ProcessMessage(getblocks, 901 bytes) FAILED getblocks 1 to 00000000df862a743db5 limit 66045
It works for a bit after restarting the client, but the exception is thrown again on a later time then Perhaps i do need to delete my blockchain and resync ? Never had this before....
|
|
|
|
d5000
Legendary
Offline
Activity: 4060
Merit: 7348
Decentralization Maximalist
|
|
August 17, 2014, 03:47:14 PM |
|
Unfortunately I get this exception too. It seems related to the old bitcoin/peercoin code Slimcoin is using (0.6x if I'm right?), if you google you will find some postings from 2012 or so in the Bitcoin forum. Have done a cron job to restart slimcoin daemon everytime it gets stalled.
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
August 17, 2014, 03:58:53 PM |
|
|
|
|
|
m5j0r
|
|
August 17, 2014, 04:50:04 PM |
|
I have contacted all pools, explorers, exchanges, etc related to Slimcoin regarding the fork.
The only question is: will you reimburse investors who lost due to the forks? I have bought SLM during the fuck up and lost quite a lot..... My wallet crashes since today too btw.... And is still missing all my coins.
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
August 17, 2014, 05:18:33 PM |
|
The only question is: will you reimburse investors who lost due to the forks?
Sure he is, in Bulgarian Lev. (which is worthless just like slimcoin)
|
|
|
|
d5000
Legendary
Offline
Activity: 4060
Merit: 7348
Decentralization Maximalist
|
|
August 17, 2014, 05:31:12 PM |
|
I have contacted all pools, explorers, exchanges, etc related to Slimcoin regarding the fork.
The only question is: will you reimburse investors who lost due to the forks? I have bought SLM during the fuck up and lost quite a lot..... My wallet crashes since today too btw.... And is still missing all my coins. I would suggest you to wait until BTER is on the right fork (user slimcoin should be able to confirm that) and then contact their support. When coins are sent in "the wrong fork" in the right fork they should not have changed owner (that's like every blockchain should work). So BTER does still have the coins, and if they're not scammers they should pay them to you. If you still have the address from where BTER send the coins to you, you can prove it yourself with blockchain explorer.
|
|
|
|
m5j0r
|
|
August 17, 2014, 06:58:50 PM |
|
Well BTER doesn't give a fuck. See their NXT wallet security for comparison.. With the ever crashing wallet there is nothing I can do anyway.
Also at the argument regarding burning coins: I can burn as many god damn coins as I want, this is an investment in an altcoin and not fucking charity. Although Slimcoin certainly has burnt my coins..
|
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 07:28:59 PM |
|
I will notify you when BTER is back on the correct fork.
The main issues seem to be these exceptions. I will have a look into them. The reason they are more difficult to test is that it is harder to find such bugs as, as of now, I do not know how to reproduce the error.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 07:29:14 PM |
|
I would like to remind all of you that Slimcoin is released under the GPL licence found at: https://www.gnu.org/copyleft/gpl.htmlAs quoted in Section 15: EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO ...
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
slimcoin (OP)
|
|
August 17, 2014, 07:41:35 PM |
|
As for the bad alloc exception, I looked around and found an explanation that is probably the solution: From https://github.com/bitcoin/bitcoin/issues/2353This is how bitcoin runs out of memory (virtual address space) while downloading blocks:
Whenever a node receives a block that it cannot link to the chain, it stores it in memory in mapOrphanBlocks. There is no limit to the size of that data. When a node is downloading blocks, it may download and keep in memory many blocks that it can't currently link to the chain. In particular, if your node connects to another node which is also downloading blocks and which is further along in the download, the other node will spam your node with an "inv" message for every new block that it downloads (no, the logic in CBlock::AcceptBlock does not prevent it), and your node will download and store those blocks in mapOrphanBlocks. This can occur with multiple connected nodes simultaneously which are at different points in the download.
I encountered this problem several times with 0.8.0rc1. With the current size of the blockchain, it is not hard to exhaust the virtual address space (at most 4GiB) in 32-bit builds, which includes all Windows builds.
The fix could proceed in one of two directions: (1) store orphan blocks on disk instead of in memory, or (2) don't keep an unbounded set of orphan blocks. For (2), the ideal would be to prevent downloading of too many orphans rather than discarding orphans that have already been downloaded, which is wasteful. The goal would be to download blocks roughly in order. One idea is to make use of "getheaders" during block download. Headers would be downloaded and linked together, and blocks would only be downloaded if we already know based on headers that they are not too far away from the chain of blocks that we already have.
How much memory does your system have? I could implement the second option, but will look into how bitcoin fixed this issue. Also, if you have any other exceptions, please post them.
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
m5j0r
|
|
August 17, 2014, 08:22:24 PM |
|
My system has 16 gigs of RAM so that is definitely not the cause unless your wallet eats 10GB+.
Also with -maxconnections=1 -connect=76.127.202.17 it says "0 active connections". If I start without it I don't get any balance and it crashes.
|
|
|
|
|