Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 94. (Read 137076 times)
@dzarmush, good to know about that shortcut. I have had full access to Library, and the Applications Support folder which contains the SLIMCoin folder.
Look for the configuration file created by the app in /Users//Library/Application Support/SLIMCoin/slimcoin.conf
Cheers
Graham
Cheers
Graham
If you don't know how to access Library, you need to click and hold alt button and then click Go menu. You'll see Library appear when you hit alt.
In the SLIMcoin folder of Applications support is where I have been looking. A "config" file doesn't exist in that folder until I create one. I've installed 2 Mac wallets on 2 machines, and in both cases have had to create this file myself.
... command line option or in the config file
1) The command line doesn't work in the console.
2)The Mac wallet version doesn't appear to create a "slimcoin.config" file. Such a file doesn't exist anywhere in the folder.
A command line option is an option provided to the command line when starting the app from a shell.
You are correct, reservebalance does not work in the client RPC console.
Look for the configuration file created by the app in /Users/
Cheers
Graham
So I'm a bit perplexed why my burn rewards got reduced by 90%.
That's the impression I got too, that mint-by-proof-of-stake rewards effectively replace mint-by-proof-of-burn rewards. But I haven't even tried to reference that perception against the reality of the C++ code.
Quote
It would helpful if there was an option to "turn off staking" on a wallet you want to use exclusively for burning.
Either -reservebalance=1000000000 as a command line option or reservebalance=1000000000 in the config file will effectively suspend staking (at least until the wallet's balance exceeds the amount specified). If you try that approach, I'd appreciate knowing whether the mint-by-proof-of-burn rewards resume their previous frequency and amount.
But a password-locked client allows mint-by-proof-of-burn whilst inhibiting mint-by-proof-of-stake. Useful to know.
Cheers
Graham
Graham, two things I noticed:
1) The command line doesn't work in the console. I tried what you suggested, many variations of what you suggested, and many others. The line simply isn't accepted in the console.
2)The Mac wallet version doesn't appear to create a "slimcoin.config" file. Such a file doesn't exist anywhere in the folder. So what I did was copy another coin's conf file over and renamed it. Then I entered the line in the config file. Result (12+ hours later): The mint-by-burn resumed at previous amount and frequency (at least for now). Staking has stopped.
You wrote, "But a password-locked client allows mint-by-proof-of-burn whilst inhibiting mint-by-proof-of-stake." My locked Mac wallet didn't allow mint-by-proof-of-burn to happen. I tried leaving it locked for a few days.
How much hashes/s are you getting from your CPUs? I've been trying to mine a few days on my OC'd 7700k in 0.3 windows version without any success, getting about 5k hash/s on 7 cores.
What miner you use? Wallet or JonnyLatte miner?
How much hashes/s are you getting from your CPUs? I've been trying to mine a few days on my OC'd 7700k in 0.3 windows version without any success, getting about 5k hash/s on 7 cores.
Another quite interesting article about blockchain and consensuses of cryptos, Proof-of-Burn, and Slimcoin, is mentioned as a one of leading, consensuses, in the crypto world.
As date states it's new - 17 Aug 2017.
https://128.84.21.199/pdf/1708.05665.pdf
As date states it's new - 17 Aug 2017.
https://128.84.21.199/pdf/1708.05665.pdf
Nice find. Good to see such a level-headed approach and maturity of understanding.
Cheers
Graham
Another quite interesting article about blockchain and consensuses of cryptos, Proof-of-Burn, and Slimcoin, is mentioned as a one of leading, consensuses, in the crypto world.
As date states it's new - 17 Aug 2017.
https://128.84.21.199/pdf/1708.05665.pdf
As date states it's new - 17 Aug 2017.
https://128.84.21.199/pdf/1708.05665.pdf
Hi, i have been reading debug.log file trying identify why slimcoin daemon on raspbery pi (with raspbian) crash so frequently.
I have found that:
At first lines you can read that getblock fuction is trying to get block on packets of 500. Suddlenly it reset the count and start again, from block 1... in this case packets of 262653 blocks. Here´s:
In few secons it consumes all memory (I have saw with htop how slimcoind got full about 600Mb of ram a 1024Mb of swap file just before throw the faliure and finally crash:
I have been locking for the code that generate the getblock fuction... I think it´s that, in main.cpp
https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L3691
But my programmings skills are so limited, I don´t know c or c++ but i can read it hardly.
Somebody could read it to get an idea about the failure?
I have found that:
Code:
getblocks 253404 to 00000007281451e91875 limit 500
getblocks stopping at limit 253903 0000000942578c720b5f (0 bytes)
getblocks 253404 to 3bfbb86e0474e8dfb756 limit 500
getblocks stopping at limit 253903 0000000942578c720b5f (0 bytes)
getblocks 253404 to 64d9ae181c771879b0b2 limit 500
getblocks stopping at limit 253903 0000000942578c720b5f (0 bytes)
getblocks 1 to 0000000f0c1baa5f2ec8 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000e63eee9fb2b62 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000c8f10b8c2133a limit 262653
likely old client, incrementing misbehaviour count.connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000005a497af15e194 limit 262653
likely old client, incrementing misbehaviour count.trying connection 180.155.8.122:41682 lastseen=-28024.5hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000169ff77e7e6903 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000181b4c9e912624 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000116f0c1e4a4b3c limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000b6916ce241de2 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000151a0612e299c2 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000ae4d14270f56f limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000b40a5a86708cb limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000005bc51aa13710 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001c0569ee0c51e1 limit 262653
likely old client, incrementing misbehaviour count.connection timeout
trying connection 65.94.75.10:41682 lastseen=-26622.2hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000b2cf653b4186c limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000002e91f0b23157a limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001b1f2ea040c19f limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000006f5e524cf638d limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001ce7f3b7b96930 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000f3d0605759654 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001b4ff5aa7723db limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000b7122fc28c93b limit 262653
likely old client, incrementing misbehaviour count.trying connection 113.106.95.46:41682 lastseen=-389780.4hrs
connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001f5b5e3021be34 limit 262653
likely old client, incrementing misbehaviour count.trying connection 151.232.214.142:41682 lastseen=-7552.2hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000001003f5885c5ed limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000464acf3dc4af5 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000e6d9a1b967a60 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000fc6ab6ddeff42 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000003f7005b0f096f limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000003a6b8f6398deb limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001335edd3b7d87e limit 262653
likely old client, incrementing misbehaviour count.connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001733659d322a3d limit 262653
likely old client, incrementing misbehaviour count.trying connection 118.126.8.18:41682 lastseen=-389780.4hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000009252e20c313ec limit 262653
likely old client, incrementing misbehaviour count.connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000df096a276b3cc limit 262653
likely old client, incrementing misbehaviour count.trying connection 130.204.61.171:41682 lastseen=-12147.9hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001198ca6e32ed61 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000009e5595a8b672d limit 262653
likely old client, incrementing misbehaviour count.connection timeout
trying connection 130.255.73.170:41682 lastseen=-389780.4hrs
connect() failed after select(): Connection refused
trying connection 149.169.122.151:41682 lastseen=-389780.4hrs
connection timeout
trying connection 87.161.65.18:41682 lastseen=-27845.4hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001038c5e534d4f3 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000001a252c674d117 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000019f1ab36c0c76b limit 262653
likely old client, incrementing misbehaviour count.connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000018a382f520379d limit 262653
likely old client, incrementing misbehaviour count.trying connection 149.169.123.98:41682 lastseen=-389780.4hrs
connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000016db4fc1502c06 limit 262653
likely old client, incrementing misbehaviour count.trying connection 67.9.132.6:41682 lastseen=-28305.5hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001508e9f8256bcd limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000003c88f63ab7ac7 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001511c49242dbd8 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001942cbec784fcb limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001e091563c8f8b7 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000002a7c5e0e83da3 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000071b67c4b2ddad limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 000000015125fa4b53b1 limit 262653
likely old client, incrementing misbehaviour count.connection timeout
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000014fdecd50e5f57 limit 262653
likely old client, incrementing misbehaviour count.trying connection 161.53.40.94:41682 lastseen=-389780.4hrs
connected 161.53.40.94:41682
connection timeout
socket closed
disconnecting node 161.53.40.94:41682
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 00000000b6fe366a154d limit 262653
likely old client, incrementing misbehaviour count.trying connection 175.195.8.141:41682 lastseen=-389780.4hrs
trying connection 86.52.165.68:41682 lastseen=-28077.6hrs
getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000fd4973700c114 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000001ce878a1225760 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
************************
EXCEPTION: St9bad_alloc
std::bad_alloc
slimcoin in ThreadMessageHandler()
At first lines you can read that getblock fuction is trying to get block on packets of 500. Suddlenly it reset the count and start again, from block 1... in this case packets of 262653 blocks. Here´s:
Code:
getblocks 253404 to 3bfbb86e0474e8dfb756 limit 500
getblocks stopping at limit 253903 0000000942578c720b5f (0 bytes)
getblocks 253404 to 64d9ae181c771879b0b2 limit 500
getblocks stopping at limit 253903 0000000942578c720b5f (0 bytes)
getblocks 1 to 0000000f0c1baa5f2ec8 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000e63eee9fb2b62 limit 262653
likely old client, incrementing misbehaviour count. getblocks stopping at limit 262653 0000000b2920ce6ec7c0 (0 bytes)
getblocks 1 to 0000000c8f10b8c2133a limit 262653
In few secons it consumes all memory (I have saw with htop how slimcoind got full about 600Mb of ram a 1024Mb of swap file just before throw the faliure and finally crash:
Code:
EXCEPTION: St9bad_alloc
std::bad_alloc
slimcoin in ThreadMessageHandler()
I have been locking for the code that generate the getblock fuction... I think it´s that, in main.cpp
https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L3691
But my programmings skills are so limited, I don´t know c or c++ but i can read it hardly.
Somebody could read it to get an idea about the failure?
“Defending Internet Freedom through Decentralization: Back to the Future?” http://dci.mit.edu/assets/papers/decentralized_web.pdf
Unfortunately, rather a predictably pedestrian view and a very poorly supported one at that, the lack of grounding work reduces it to the level of an over-indulgent blog post.
Whereas Roy Baumeister's “Is there anything good about men?” might be a decade old and from social psychology but it has more to contribute than the above in practical considerations of decentralisation.
Cheers
Graham
Unfortunately, rather a predictably pedestrian view and a very poorly supported one at that, the lack of grounding work reduces it to the level of an over-indulgent blog post.
Whereas Roy Baumeister's “Is there anything good about men?” might be a decade old and from social psychology but it has more to contribute than the above in practical considerations of decentralisation.
Cheers
Graham
do you know what's up with ACME block explorer?
It's not up for a few days, it's worrying me a bit :/.
It's not up for a few days, it's worrying me a bit :/.
Keep calm and carry on.
ACME is in development. And as I have repeatedly observed, I have other responsibilities. As to your worries, I've also posted an image of github commits stretching back years, perhaps you can find something in that to assuage your concerns.
ACME may not be fully up to date as I am working on the automatic maintenance scripts but it is serving on http://tessier.bel-epa.com, port 5064. I've copied over bchain.info's list of addresses ordered by balance and remapped the addresses to ACME as a draft exercise, it's available via Transactions->Addresses listed by balance. Looks like I need to add pagination as a priority.
You'll also note the commits to the Slimcoin ACME branch: https://github.com/gjhiggins/acme/commits/slimcoin as I gradually complete the migration to a deployable package.
Cheers
Graham
@gjhiggins - do you know what's up with ACME block explorer?
It's not up for a few days, it's worrying me a bit :/.
I know you were tuning it up, but I thought it would be up within 2-3 days, and now is almost week? I don't know, but some days passed.
I hope it will be up, and all feautures will be included, maybe you want some help with it?
It's not up for a few days, it's worrying me a bit :/.
I know you were tuning it up, but I thought it would be up within 2-3 days, and now is almost week? I don't know, but some days passed.
I hope it will be up, and all feautures will be included, maybe you want some help with it?
So I'm a bit perplexed why my burn rewards got reduced by 90%.
That's the impression I got too, that mint-by-proof-of-stake rewards effectively replace mint-by-proof-of-burn rewards. But I haven't even tried to reference that perception against the reality of the C++ code.
Quote
It would helpful if there was an option to "turn off staking" on a wallet you want to use exclusively for burning.
Either -reservebalance=1000000000 as a command line option or reservebalance=1000000000 in the config file will effectively suspend staking (at least until the wallet's balance exceeds the amount specified). If you try that approach, I'd appreciate knowing whether the mint-by-proof-of-burn rewards resume their previous frequency and amount.
But a password-locked client allows mint-by-proof-of-burn whilst inhibiting mint-by-proof-of-stake. Useful to know.
Cheers
Graham
Funny thing happened. I have a dedicated Slim Burn wallet on a computer I use only for this wallet (i.e. my staking Slim wallet does not reside on this computer). Anyway, regular and healthy sized payouts of coins had been coming in thanks to burning.
After a couple weeks the staking started up (I suppose because my wallet was unlocked). Staking rewards suddenly started appearing.
Exactly coinciding with the onset of staking rewards, 1) my computer slowed way down and 2) the burn payouts reduced to a trickle and became smaller in size. Though I was now getting small stake returns, this didn't compensate for the huge reduction in burn payouts.
I'm assuming I shouldn't have left the wallet unlocked on my dedicated "burning wallet/computer" because staking takes too much processor power, even for small amounts.
What I learned is not to mix burning and staking, and therefore, to always burn with the wallet locked.
The thing I can't explain is why the onset of staking rewards would reduce burn rewards. Although the computer was slow, it was working enough to support several other non-Slimcoin wallets that continued to get staking rewards, and I understand burning isn't processor intensive. So I'm a bit perplexed why my burn rewards got reduced by 90%.
After a couple weeks the staking started up (I suppose because my wallet was unlocked). Staking rewards suddenly started appearing.
Exactly coinciding with the onset of staking rewards, 1) my computer slowed way down and 2) the burn payouts reduced to a trickle and became smaller in size. Though I was now getting small stake returns, this didn't compensate for the huge reduction in burn payouts.
I'm assuming I shouldn't have left the wallet unlocked on my dedicated "burning wallet/computer" because staking takes too much processor power, even for small amounts.
What I learned is not to mix burning and staking, and therefore, to always burn with the wallet locked.
The thing I can't explain is why the onset of staking rewards would reduce burn rewards. Although the computer was slow, it was working enough to support several other non-Slimcoin wallets that continued to get staking rewards, and I understand burning isn't processor intensive. So I'm a bit perplexed why my burn rewards got reduced by 90%.
Correction to what I wrote above: I can't burn unless I have unlocked the wallet.
However, as stated, after I have left the wallet unlocked for a few weeks, staking kicks in and slows down my computer. And the computer slows down even though hardly any coins are being staked (just the new ones I received from doing burning).
It would helpful if there was an option to "turn off staking" on a wallet you want to use exclusively for burning. This way you could run other, non-slim wallets on the same computer, and the computer wouldn't have to be powerful. Lacking such an option, it looks to me that if I want to continue burning the coins I started burning, I'm going to have to devote a second computer to Slimcoin, simply because I can't turn off staking on the wallet I've dedicated to burning.
Crisis: adverted.
Just so everyone is quite clear on this .. there was never any “crisis”.
This is a classic instance of “a little learning is a dangerous thing”. The bitcoin codebase is complex, commented not documented, developed not designed and its full comprehension makes significant technical demands. The unfortunate result of this is that your concerns arose as a result of your own technical limitations. (I choose to ignore the possibility that, given this is bitcointalk, it might just be immature, attention-seeking behaviour.)
There are several quite accessible guidelines for coordinated vulnerability disclosure, (e.g. The CERT Guide to Coordinated Vulnerability Disclosure). I recommend that you familiarise yourself with the principles and practice so as not to cause those more technically knowledgeable to waste their time responding to unsupported and ill-founded public challenges of the security of the coin's functioning.
Kudos to d5000 for taking the time to respond, has more patience that I do, clearly.
Cheers
Graham
A Little Learning
by Alexander Pope
A little learning is a dangerous thing ;
Drink deep, or taste not the Pierian spring :
There shallow draughts intoxicate the brain,
And drinking largely sobers us again.
Fired at first sight with what the Muse imparts,
In fearless youth we tempt the heights of Arts ;
While from the bounded level of our mind
Short views we take, nor see the lengths behind,
But, more advanced, behold with strange surprise
New distant scenes of endless science rise !
So pleased at first the towering Alps we try,
Mount o’er the vales, and seem to tread the sky ;
The eternal snows appear already past,
And the first clouds and mountains seem the last ;
But those attained, we tremble to survey
The growing labours of the lengthened way ;
The increasing prospect tires our wandering eyes,
Hill peep o’er hills, and Alps on Alps arise !
http://poetsgraves.co.uk/Classic%20Poems/Pope/a_little_learning.htm
I'm looking over the block creation code (https://github.com/slimcoin/slimcoin/blob/afd8ef7e18e17f876f0bc7b44e79ee867f0b3ac1/src/main.cpp#L4931) and I'm wondering:
What is stopping miners from changing the block decay to a constant? What is stopping them from replacing that whole statement with something that makes nEffectiveBurnCoins an absurdly high number?
What is stopping miners from changing the block decay to a constant? What is stopping them from replacing that whole statement with something that makes nEffectiveBurnCoins an absurdly high number?
I'm not a programmer (I know a little bit of Python and can read - but not write - basic C/C++), but I mean to interpret that this code is not determining the chances of an individual "burn minter" but is instead calculating the EffectiveBurnCoins "score" of all burn minters combined (nEffectiveBurnCoins) which is stored in the block header.
So if a miner (only a PoW miner could do that, because this code only works in PoW blocks) sets this value higher, then _all_ "burners" would have a higher "score". So nobody would directly profit from that "attack". However, I would be surprised if that value is not validated when the nodes check the validity of blocks, because it should be easy to see if this value is manipulated.
Perhaps someone with better C++ understanding can confirm that or link to the part where the correct nEffectiveBurnCoins value is validated.
PS: I think I found the code (in: CBlock::AcceptBlock()):
Code:
// The effective burn coins have to match, regardless of what block type it is
int64 calcEffCoins = 0;
if(!CheckBurnEffectiveCoins(&calcEffCoins))
return DoS(50, error("AcceptBlock() : Effective burn coins calculation failed: blk %"PRI64d" != calc %"PRI64d,
nEffectiveBurnCoins, calcEffCoins));
From my understanding, that means that only a cartel of 51% PoW miners, 51% PoS minters and 51% burn minters could build a chain with a manipulated nEffectiveBurnCoins value. Even then, other economic nodes would not accept this chain and the minority chain with the correct value should be the one that will survive (OK, if Bitmain or another bad mining guy tried to mine on that chain maybe we would end with a "Slimcoin Cash"
, but it wouldn't make any sense to use it).Yes you are correct. I couldn't find the validation code - but you have! Woohoo
Crisis: adverted. 
I'm looking over the block creation code (https://github.com/slimcoin/slimcoin/blob/afd8ef7e18e17f876f0bc7b44e79ee867f0b3ac1/src/main.cpp#L4931) and I'm wondering:
What is stopping miners from changing the block decay to a constant? What is stopping them from replacing that whole statement with something that makes nEffectiveBurnCoins an absurdly high number?
What is stopping miners from changing the block decay to a constant? What is stopping them from replacing that whole statement with something that makes nEffectiveBurnCoins an absurdly high number?
I'm not a programmer (I know a little bit of Python and can read - but not write - basic C/C++), but I mean to interpret that this code is not determining the chances of an individual "burn minter" but is instead calculating the EffectiveBurnCoins "score" of all burn minters combined (nEffectiveBurnCoins) which is stored in the block header.
So if a miner (only a PoW miner could do that, because this code only works in PoW blocks) sets this value higher, then _all_ "burners" would have a higher "score". So nobody would directly profit from that "attack". However, I would be surprised if that value is not validated when the nodes check the validity of blocks, because it should be easy to see if this value is manipulated.
Perhaps someone with better C++ understanding can confirm that or link to the part where the correct nEffectiveBurnCoins value is validated.
PS: I think I found the code (in: CBlock::AcceptBlock()):
Code:
// The effective burn coins have to match, regardless of what block type it is
int64 calcEffCoins = 0;
if(!CheckBurnEffectiveCoins(&calcEffCoins))
return DoS(50, error("AcceptBlock() : Effective burn coins calculation failed: blk %"PRI64d" != calc %"PRI64d,
nEffectiveBurnCoins, calcEffCoins));
From my understanding, that means that only a cartel of 51% PoW miners, 51% PoS minters and 51% burn minters could build a chain with a manipulated nEffectiveBurnCoins value. Even then, other economic nodes would not accept this chain and the minority chain with the correct value should be the one that will survive (OK, if Bitmain or another bad mining guy tried to mine on that chain maybe we would end with a "Slimcoin Cash"
, but it wouldn't make any sense to use it).
Staking make is quite CPU hungry that's true, but on my PC it's like 10-15% max.
I wonder when will beta-ACME ressurect ? It has been down for days now.
I wonder when will beta-ACME ressurect ? It has been down for days now.
Just wanted to report that I finally upgraded my node (daemon-only) to the latest github master branch on Debian7-amd64 without any problems.
Its running now for two days and does well so far. However, no chance of staking even with only 500 coins (brings the machine to the speed of a pocket calculator). Slimcoin is in my experience the most demanding wallet (the PoS part) compared to any other I have ran and still run.
Its running now for two days and does well so far. However, no chance of staking even with only 500 coins (brings the machine to the speed of a pocket calculator). Slimcoin is in my experience the most demanding wallet (the PoS part) compared to any other I have ran and still run.
Jump to: