 Show Posts
|
|
Pages: « 1 2 [3]
|
The problem is if you apply this model to Proof of stake, it would be a "rich getting richer" game, as large holders probably will get much more rewards than today. In Slimcoin's Proof-of-burn, not the rich but the people which take most risk are being rewarded, so the reward structure is good in the way it was implemented.
The way I see it the PoS rewards would be the same (1%pa) if every one mints as the probability of finding a block would be weighted by your stake/coin-age to make it so. The big difference would be that if a large holder stops minting then their blocks would be found by someone else where as in the current model they keep accumulating coinage and so their chances go up and so does their reward. I don't really know the technical details as it is something Sunny King just mentioned he is thinking about and I didnt think much of it until trying out slimcoin. That's a very good idea ... burnt tips! I have no idea though if this is technically feasible. From my layman's point of view there should be a way to do this, but it would need a new transaction type, I guess. ( it should have to automatically transfer from address a (donator) -> address b (beneficiary) -> burn address, without the donator having to know the beneficiary's private key)
I think you could use OP_RETURN to specify the beneficiary's public key hash I don't think anything needs to change for the transaction to happen (other than adding an interface in the clients) but the code that checks to see if a PoB block is valid would need to change to incorporate the change: invalidating PoB blocks that point to burn transactions that have a specified beneficiary but are signed by the sender and considering the ones valid that are signed by the beneficiary as valid. No need for the beneficiary's private key, you would just need their address to get the public key hash. You would also need a way for clients to know they have received burned coins. Its a bit clunky I admit. |
|
|
|
|
I am mostly a peercoiner but slimcoin has gotten my attention because of it being the first proof of burn currency, at first that was a slight curiosity but after trying it out I noticed one thing. Slimcoin has a much better incentive to keep a node online all the time than peercoin, in fact since I burned some coins my node has pretty much stayed up constantly. I dont want to turn it off because I would miss out on collecting (these admittedly almost worthless) tokens.
Although I have a peerbox (raspberry pi setup as a peercoin node that you can just download the image for and have a reasonable amount of confidence its secure) I use that as a kind of charity to have a node on the peercoin network but my minting machine almost never comes online: a few days every couple of months. This will change at some point when peercoin adopts a proof of stake model that is more like slimcoin's proof of burn: same block reward for anyone who gets a block but an increased chance of finding one if you have more stake.
Anyway, I was thinking of ways to increase adoption of slimcoin, not just to have people buying a few as a speculation but to actually have them burn some and become part of the network. My idea is this: change the protocol so that when you burn coins you can specify the burned coins to be associated with a different address instead of the one you burned from. This would allow me to send someone burned coins but it would not allow for the trading of burned coins. A faucet and reddit tip bot could be setup for people who would like to try minting with slimcoin and you could actually give people a decedent amount without worrying that they would immediately sell for their favorite currency.
|
|
|
|
|
I have the dcrypt function working on a GPU already using the pseudocode from wikipedia for sha256 and the buffered method. Its just a matter of taking or writing some network code to feed in a valid block header to use as a template and then scan through the results for found blocks/shares and send the results back. I have network code I understand (because I wrote it) that gets work from jsonrpc so that will get done first and I'm sure Stratum is not difficult. The other option is using the CPU miner code but a quick look at how it mines shows something slightly incompatible with what I think is needed (it loops through nonce individual and returns nonce for found block/share, where as I may need to be able to send back multiple shares so I'll have to learn what to change in code I don't fully understand the process flow of, perhaps someone could help me with that but I dont want to give away the GPU code as anything other than a release of the client for cynical reasons) I also want something that can mine in a pool but then fallback to solo mining if the pool stops working.
Right now I have to sleep though since its Australia outside here.
|
|
|
|
https://i.imgur.com/f58pg0U.pngThis is just a hint about something I may be working on. No time-frame available but I will update here when code that does things gets connected to code that talks to things.
|
|
|
|
|
a123 Messaged me saying he would review my code but that he is currently away on a cruise with limited internet access which is unfortunate timing with the pool.
Anyone still working on p2pool?
|
|
|
|
|
You could also check to see if you have enough virtual address space.
It seems this problem was solved for bitcoin since 0.9.0 by restricting the number of orphan blocks that are stored.
|
|
|
|
Are you using this release? https://github.com/kryptoslab/slimcoin/releases/tag/v0.3.2.1I have not had any problems using it. How much RAM do you have? While I'm on the topic of RAM, its possible to completely eliminate the dynamic memory requirements of the dcrypt function:
#define SHA256_HEX_LEN 64
uint256 dcrypt_progressive(const uint8_t *data, size_t data_sz)
{
//if(fTestNet) return sha256d(data,data_sz); // for testnet hashes use sha256d
SHA256_CTX ctx; // sha256 context
uint256 hash_result;
uint32_t index = 0;
uint8_t index_values[SHA256_HEX_LEN +1];
uint8_t scratch_pad[SHA256_HEX_LEN +1];
SHA256_Init(&ctx); // initialize context which will progressively hash the result as data for it is generated in scratch_pad
sha256_to_str(data, data_sz, index_values); // initialize index_values with sha256(data) -> ascii/hex
memset(scratch_pad, 0xff, SHA256_HEX_LEN); // initialize scratchpad all 0xff
do
{
index += hex_char_to_int(index_values[index]) + 1; // increment index by the value of the hex char in index_values and add 1 so index is always increasing
if(index >= INDEX_BUFFER_LEN) // if index is past index_values size, wrap index around and scramble index_values
{
index &= 0x3f; // wrap index around
sha256_to_str(index_values, INDEX_BUFFER_LEN, index_values); //rescramble with sha256(index_values) -> ascii/hex
}
scratch_pad[SHA256_HEX_LEN] = index_values[index]; //set a byte in scratch_pad to index_values[index]
sha256_to_str(scratch_pad, SHA256_HEX_LEN + 1, scratch_pad); // sha256 hash
SHA256_Update(&ctx,scratch_pad,SHA256_HEX_LEN); // write scratch_pad to the sha256 context that will generate the resulting dcrypt hash
}
while( (index != SHA256_HEX_LEN - 1) || (index_values[SHA256_HEX_LEN - 1] != scratch_pad[SHA256_HEX_LEN - 1] ));
// loop ends when index is at "SHA256_HEX_LEN - 1" and the value of index_values matches the value of scratch_pad at that location
// this should have a 1 in 16 chance for every time index happens to hit "SHA256_HEX_LEN - 1"
SHA256_Update(&ctx, (u8int*)data,data_sz); // write the original data to the sha256 context for the resulting hash
SHA256_Final((u8int*)hash_result, &ctx); // finalize the hash and store the result
return hash_result; // we are done here
}
Instead of building up a buffer and hashing it at the end this version progressively hashes the data generated. Sha256 contexts have an internal buffer which is of fixed size. So it seems dcrypt was never memory hard except for the fact that you can get a minor optimization with hashing by buffering the data instead of hashing progressively and then aborting if the resulting buffer gets too big. The optimization is not that you are saving memory or preventing too much memory use, its that you are not hashing longer buffers saving the processing of the large data. This is probably why there isnt a spectacular increase in efficiency by limiting the number of iterations (you are only really saving one sha256 call on the larger buffer but still wasting many small calls for calculating the scratchpad and index values) In any case I think this version of Dcrypt algorithm might be better for the main client to prevent too much resource usage while we wait on the possibility of a change in hash functions. I dont think its bad that Dcrypt has fixed memory usage. I hope my code is a clear implementation that could be of help to someone writing a GPU miner which I now believe should not be too difficult to implement (the problem is now variable computation time instead of variable memory usage) If we have a GPU miner then it will be much harder for a botnet or server farm to compete and if we can do it with dcrypt then changing the hashing function is less important... |
|
|
|
Its probably the change to the hex code as it uses more memory. I just rebuilt with the old hex lookup but obviously keeping the iteration limit. The improvement for my desktop (core 2 duo) was noticeable (20-30%) so perhaps we need a low power and high power build(s) There could be a middle-ground too with a smaller lookup or the original code unrolled. The previous build I zipped using the windows built in functionality which could be why github wouldn't take it. This one I copied out of my vm/build environment onto my pc to zip so make sure to virus scan it as I'm less confident about my web surfing computer being clean. http://www17.zippyshare.com/v/94055711/file.htmlEdit: needs the dlls from the other download so I have renamed it so you can put it in the same folder. |
|
|
|
Ouch. Bad news galore  On the bright side, we must have quite a bit of volume today on Bter and prices have fallen, so acquisition and mining would hopefully be cheaper. The coins would also hopefully have been bought by people committed to the growth of SLM. I learnt about the weakness once someone about 4 pages back mentioned about the low scratch space requirements, and the slimcoin.club web miner was experimenting with an iteration limit of 64. The improvement is actually rather little, around 20% max and you have to tweak for an optimal iteration limit. I haven't checked johnnylatte's hex acceleration routine. However, once this news gets out (like now) I suspect it would be trivial for experienced GPU coders to accelerate it, if it wasn't already. POB uses single-SHA256 and not dcrypt, so no iteration-based improvement would help it. The dump is likely by someone with a GPU miner or a botnet; I've seen single addresses recently hashing with over 5MH. I'll try to quickly implement the changes into the miner and release it; that should help level the playing field and buy us some time to change the algo, or just go completely GPU friendly. I'm still for a version of CPU only algorithm though, but we oughta use one that has been well established. My improvement was 20% as well plus another ~30% for optimizing digest_to_string, feel free to use my code for that in the public miner but I will keep my acceleration to myself as its not an improvement over what you have and it sounds like they have done the exact same thing as me anyway. I also set REALLOC_BASE_SZ to (MAX_COUNT * 64 + SHA256_DIGEST_LENGTH) so that the buffer never needs to be expanded since realloc is expensive although they may want to do that in a way that can be adjusted on the command line if the right iteration limit is very different for different computers. You can also make the buffer a global variable and initialize / free it separately so that you are not constantly allocating and freeing it. Have you considered talking to Sunny King (the developer of Peercoin and Primecoin) for suggestions on PoW. He has helped out other altcoin developers in the past and being able to think of and develop Cunningham chain based PoW shows he knows what he is talking about at least. Now that I think of it he has gone down both paths that we are evaluating without trying to go down both at the same time in the same coin. |
|
|
|
Sample count values [seem to] confirm extreme optimization for processing over memory usage with occasional high values. So who is mining with their own software? 000000038e6a9957b844ea8060e4698ba266ff11a2dc70762b2f99b95999d76b
count 15
000000128aeb72d82db57a7cc74713fb932e951900de7a32a00884f34538b624
count 8
0000000ac812662e5f47f7069cd931f5c1e076f665e8a4ee783f75595fcbe6b6
count 32
0000000fecfa2c3e370b7035bd0bd8bf3c1160a9af41fdc954fa700e7a8d53d7
count 7
6eaa5b2bae0f8af242ee5fafa47406e444d47d93c9bbf7c8ee083079ffb03e20
count 72
00000000040cf7965c277f0f91202368744d1782fe9cbe1b7483988147f9e05c
count 5
47c06e5399e203b793814762ad008ba71f22cac4b04d6d3eb4a0ba00e7bf5257
count 1645
0b4ad69186e8f51816c4735460c335b544478108e4b62657b1fe4f1f8af59bcb
count 677
d9a60bbeac2a396a987d1ee8df71aae60a03e55b3e4e0d5d0a56300cfd5bc1d9
count 3337
82908d5862545b2944770d80ac6e268633eb300194d30e992f89739eee34ec0d
count 1659
00000005a749a6f731b06896c1f01aab9a4753e228ee78f69c7d06ae6bcf2d7c
count 6
000000060fa51f39a3ae21051b37720bb3972538eb95dea4610d5e2d11382c7c
count 7
00000010e9a669624e6528b5c4f2f4def09dca8364f860288ecb2a5f94f4347d
count 9
0000000a50c04bc270ad337143dd911308361d75091785a1b98bf35aa3eb8a16
count 11
0000000dbe67c7c55dbdc06bc13aff005a7e6d161a8f5c702509b02ccc06b6b3
count 6
df5495833a855960b641f5664a86643c53166661ed114925e1087c442efaea6e
count 807
000000009ee55c346b7606d95640dfcd43eddce27b65353783a0b614fba944e1
count 13
00000003fc72396f0993e1b91f329e19e8bd11b46ace9d0dba938173d5bcca6d
count 9
de20e1b3d9f85cd65fec37eeb332e38bf716b1e21f16f7ccec770edc8eeda71c
count 2133
0000000460bf0215bcea46a53e4be2dcf9841107a9ab20edae1b6c8b1b35f612
count 6
00000003d5432e8a53a12d9bebffbd6ee5f0d7379083d1efea657e11ddd5c2c1
count 6
00000004c75b3ff5139a4df7ed89b9d8c0c4c0710ec21f6e6bed06ded804f1ac
count 17
adefca97290494af097da26c4ffb08d0328480d9baf0bb744e6104fe669d66e8
count 163
000000009e33504d70da2b4b5af388290c5d59d5193b0f66331441f6e8079f1d
count 7
0000001118288b91973e93f7deea538799c7cbbe17438d937993add78921fce3
count 6
00000010c5e6aea9ee9d6c92c17792c026cfde067d7623f5f1345cd7499bb8f9
count 13
396249ae28d144959cf5c906cc4c54e4b2cf38fcdefbe8c23c5d26ac25d095e8
count 2915
0000000445068863752b7047b7bcfaa218778afa1192fb6988fcdc09fe064fd7
count 9
0000000ac52b23f39971e2b71f4f22ed903f87ec0dfe2ff34b8c543a6c4fbed2
count 32
324bc41a5458272d6196189d4e0ced3a3c91ef93cf7c3b68cd057d62b5cda068
count 632
0000000ebef69b1be03eef1e3a29d799a9c2128f84a45ae967b6bca922b4b563
count 11
c7c6de90b9dc4af55a4199100102cc4ef6f331814a5758f3d616a1507a716775
count 1885
0000000ab81cc123afd226ec6fc2fc213f02fa7b23a59769e5961b5af8121615
count 26
000000045001339273a41ec13435ebac288356cf1961c949f7b52c07bc987fca
count 8
8047ba3d706a39c0895905e5a3c1a456c1b656de2e5daddb40100c06d9fe424d
count 183
0000000d5afef5da78afe0016a0c35a22194b159b941a6457ddf862e924bfcd6
count 10
0000000f8b1f509c77ec38d1c0071e0cd13ddce4981002a1309d64ad8080971f
count 8
0000000ca3d9626968dd8ec767b979d310c81fa30eeaca9dd16d0d3983e7d4dc
count 25
8d2649268866a90c031e730ca51831c09e4648efa3f4d062e7a55a760acaeb9d
count 345
0000000643c0bd94913394a9ffd8e1ac98f79b7a6853bdfb7e8b18a879335a8e
count 11
2934ceb326a678f457d3a20a8142674c98794e54eaa2ce2984fffeff68fff977
count 4740
000000048fbcb7776d87aa58980e58824ba47542c396b8e7b65139f02be8d0a4
count 9
00000009223bb37341f9dde8d3e60155e18345b2c3eabf9104406c346446ce50
count 21
3f3a0f90c3d59ba183a9cc072e77501f392996f1b59f9df216c2bb4827234c63
count 387
000000007e36aab2351964c79301ec7c1135ba9e6cc9e2a9a41312987dcf9c70
count 8
000000059521b6f84e09c7022ad92c4a5454a917e83f5edcb6d509db72aa3215
count 7
00000002573db764e063e7cc1d81c281f2e76c4711d415a7662bb3be77aab1a5
count 21
b75680795414633d78f8fd3139ecb19de108c2ba1edefebe1cfd7572766229eb
count 183
00000006c7940055f75c84b6529d5aeb47a5f8645d2109bf4fb0272d80023bd5
count 10
f902f8137934436067948d44dc431540dd9a6e894446cb55a291b9f3cb76d81a
count 331
000000125ac03b677a2a16a250d66e3e51ffab85673a6017bf8b739df008f614
count 7
28955efff0c516acbc9af85a6903d5b1f6b34b0de7d83b7c243ecafdc84d1d0e
count 428
0000000614d9ddb8ee337dfc46092967bb5c781a71132d3178818f711b0ce7c4
count 11
0000000dee329cd6f7170a750da1c126a6a5daa1dd105ed8ba3a1b58d3b944eb
count 22
00000000f490215c5928584a6bcf820c04ae0ba731b3f416c8d35b8c3e77e0fe
count 13
12bd6668a2f0e6a1e56343e7af3a51c4d233e1f185816aa4eba886c300f8f2d6
count 210
0000000990d14ce9d38cc36fea610e2724425c347e7ca72729348141ced43c1b
count 8
00000007d850d5e0e0a96af5bac47cc5230f8cc4851c8b11d517eac55c2673eb
count 13
00000000e51275c1e604beb66a56da83d16cc77a31b255f1decdf4ed1e44cac5
count 27
f778b34e3d3a4a6473ee42fa6764938415f82d3f707ea0ad4f877a0f2b086f6b
count 602
6beab7df276e7612bdbc9577466694e247241f638f96061961454fffbf20c3c0
count 2475
0000000e86c08b4565de175fc1963f7ae2d3bc1ae67c03eb59fc13d1d0b90549
count 13
00000002c37383eae029efd49bee927e89e8e0b8577f593d9e5f908b02f4adce
count 6
0000000a6ac4e1a39734a199839bcbdc57407c455f0de499d4114434e899301a
count 6
00000004ea968db722b68d59093c4711198e578f28bc2e9491e6441e049f74f4
count 19
a0cbd163d83cd3243f4eefe9b6ee84a01ee614af72fb08bf31852f497eb41b04
count 543
000000119ebaae15f17bd94dc85f48391cb9133d281e2f511e5df157a6487f43
count 21
0000000279764e347b1b52ec3ee1bdb81bcfc53ba24cd20b6ce0b0db74fe9ddb
count 7
00000002941ad3fd55c9333133bd541e6de681bbf44044cfeb7bee2fba63abca
count 7
000000011fa7cd793541599011c199fdb74099c55ca96e3e7a194a364d1ab749
count 7
00000009ded7315547a282a01d6dfc94e7fdf650d93b1e5ac8ffe6348e279eba
count 8
8261ac08781a2e2387423c5f45d1739fa4d3504fac4548b7f089fcb4641b32d5
count 18
0e8986e725d02a8a0ec98dee57528109576bfc524e6cd5656978fc3ebcb85a9c
count 223
0000000a26d9504d999512367cf9d76cd3741571c6b0dd050cde190b5a384b3f
count 19
0000000830f97483c789681ca23bb04cc60e2045fb1ce412ff7ab6d7ba65e67b
count 13
0000000080240b55e8c7ec544e9f09392831c95350e898b3b5739c4307f12a28
count 7
000000054c4b048c23b2f4c3637e0afca687640443c734eaead0a8408488402a
count 9
b8303053a77f62d7580a775654c2468a266c5d21a1d4a170e2d917fb6faaa574
count 7
0000000dfa71f6302652aa807def51a5f5931486b16c5ae59b7b0e2b6e1be2d8
count 9
371273bb52588dee39fa2161976d06c9b5de3cc5a7b817f883bc2b2ff3c00a2b
count 2086
09edbf05b9a0c471549dc8b42f2a9ce61d0c5bd497e82f04ceed20db3e379924
count 791
0000000c4e6963ef6e2b585e78f544caabc1bf9e19b4d54c97ecfb266c6d1e9c
count 12
c9f472f32b9dd5158772556a60a41d1b0fc5beccb77f9cbb8fc996a33d590cad
count 476
be908605235d5137bdd4bcffc71acf971c4766b383732c3727ba2a23deb6fec0
count 3398
0000000fea63e7e334669130519052369e27debb4a954a51b8a637bc2f691ca3
count 19
00000012be129110eedef78d7a07643735b0f02be06160501f2a9a0fb19f52f3
count 18
000000056f22d66b38dd94a0406e0a814a83c7f7d22047f16b38a23a943e1ed4
count 32
a339291b62c15754d149f2300656b4deec69c3b01152e33f3cf24c4821ee0aff
count 2761
0000000c7e6529e5f81c369903db173c065448f000a80adbdad58dffce983b73
count 32
0000000c472938828c6b0238c3cb64ea0a18c8f94626f556d6d20b24f8c85671
count 8
347319680150db0544a38e4abf50ab7a039b3e82267a7c4eb89815622744f5b2
count 268
00000009f109ea6e95c9989ec38d122cc47818ca2ea5f247657233e9b762428e
count 27
0000000b8b1907f2e6491e6cf0f65696782dcccce5266b5d821156395e22c333
count 9
0000000a29c2f3526e92bc419c477252021f245571d9cea14f00801c2b597f23
count 9
ab0a14d9a24a884a228ed73e6433a3d79a5e226a203d26e1448d33b4a199b48f
count 250
00000007d78d1c092d6f9d606917985e0064928f5228297fd28fbbda2e73a9e9
count 7
36c37f4931b621e0d7081f3ccb08cab36e8122d56d1013b7b7a9e8c11f9369e8
count 4863
00000011c27ebd218e6bc269400f740b9fc48c269f53a7f38f552ddddb112b76
count 6
0000000f613c26eb5a1b4fdce5171790e9e351929c020ca5173380cf4276e2ec
count 8
EDIT: Just did the calculation on a few blocks I minted myself with PoB and found their count values to be in the range for random hashes, as expected. |
|
|
|
I just hashed all the block headers in the blockchain file (did not prune orphans because meh) and found the average "count" multiplier for the internal buffer size in lots of 1000 blocks. Here is the results:
1000: 1035, 2000: 1014, 3000: 975, 4000: 955, 5000: 1022, 6000: 1082, 7000: 929, 8000: 947, 9000: 931,
10000: 898, 11000: 845, 12000: 916, 13000: 1015, 14000: 1053, 15000: 1016, 16000: 1050, 17000: 976, 18000: 933, 19000: 969,
20000: 937, 21000: 938, 22000: 868, 23000: 774, 24000: 781, 25000: 838, 26000: 699, 27000: 887, 28000: 909, 29000: 850,
30000: 899, 31000: 845, 32000: 791, 33000: 730, 34000: 770, 35000: 685, 36000: 675, 37000: 707, 38000: 681, 39000: 648,
40000: 570, 41000: 539, 42000: 530, 43000: 524, 44000: 449, 45000: 222, 46000: 297, 47000: 665, 48000: 434, 49000: 431,
50000: 511, 51000: 587, 52000: 504, 53000: 346, 54000: 421, 55000: 505, 56000: 862, 57000: 878, 58000: 814, 59000: 496,
60000: 278, 61000: 280, 62000: 311, 63000: 326, 64000: 240, 65000: 231, 66000: 263, 67000: 369, 68000: 336, 69000: 311,
70000: 287, 71000: 274, 72000: 330, 73000: 346, 74000: 317, 75000: 338, 76000: 344, 77000: 385, 78000: 381, 79000: 344,
80000: 374, 81000: 417, 82000: 424, 83000: 341, 84000: 368, 85000: 336, 86000: 384, 87000: 395, 88000: 385, 89000: 338,
90000: 352, 91000: 404, 92000: 386, 93000: 368, 94000: 323, 95000: 369, 96000: 337, 97000: 381, 98000: 430, 99000: 331,
100000: 372, 101000: 379, 102000: 369, 103000: 305, 104000: 339, 105000: 359, 106000: 305, 107000: 362, 108000: 311, 109000: 305,
110000: 323, 111000: 327, 112000: 318, 113000: 290, 114000: 370, 115000: 302, 116000: 283, 117000: 329, 118000: 327, 119000: 361,
120000: 345, 121000: 359, 122000: 344, 123000: 331, 124000: 349, 125000: 340, 126000: 291, 127000: 259, 128000: 295, 129000: 292,
130000: 283, 131000: 272, 132000: 276, 133000: 253, 134000: 258, 135000: 292, 136000: 269, 137000: 270
Up to block 17000 the internal multiplier looks like what I what I got from sequential data (basically random hashes) but from there it steadily counts down. I'm not sure if this is evidence of a GPU miner or someone who is optimized for low memory usage on a CPU or something else. But the most likely explanation is that someone or many people are mining hard with a software that is optimized completely in favor of processing power over memory usage. I would expect that even if there is a GPU miner the hashes from PoB blocks would make the internal hash more random though. What is the ratio of PoB blocks to PoW blocks? |
|
|
|
I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.
A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing void digest_to_string(u8int *hash_digest, u8int *string) in https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.cto
char * byte_to_hex =
"000102030405060708090a0b0c0d0e0f"
"101112131415161718191a1b1c1d1e1f"
"202122232425262728292a2b2c2d2e2f"
"303132333435363738393a3b3c3d3e3f"
"404142434445464748494a4b4c4d4e4f"
"505152535455565758595a5b5c5d5e5f"
"606162636465666768696a6b6c6d6e6f"
"707172737475767778797a7b7c7d7e7f"
"808182838485868788898a8b8c8d8e8f"
"909192939495969798999a9b9c9d9e9f"
"a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
"b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
"c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
"d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
"e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
"f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";
void digest_to_string(u8int *hash_digest, u8int *str)
{
register int si = 0;
register int i = 0;
for(; i < SHA256_DIGEST_LENGTH; i++)
{
memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
si+=2;
}
str[SHA256_LEN] = 0;
return;
}
Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash. I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better. I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is. |
|
|
|
|
I wrote a program to examine The Dcrypt Algorithm just out of curiosity. I wanted to know how much memory it uses on average. Internally in the mixing hash function it has a scratch pad that exists as multiples of 64 bytes plus the original size of the data being hashed and some fixed sized scratch pads. The variable size buffer is what is of interest because that what is supposed to fight against GPU and ASIC miners.
After hashing 100K times I got the following result for the multiple:
average 1026 <10 0.683007% <100 8.99509% <500 38.3704%
So on average the function used 65,664 bytes for the variable sized buffer but 0.68% it used less than 640 bytes.
I though this is interesting and it should be possible to see if anyone has a miner that aborts hashing if the memory size of the hash function is over a certain size.
|
|
|
|
|
So there is still the PoW cost but how do the PoB blocks then contribute to the consensus?
How would an attacker with 51% of the PoW fair against defenders with various levels of burned stake?
|
|
|
|
|
How does slimcoin deal with the "nothing at stake" problem? is it applicable?
I can see in the event of a PoW fork it would cost next to nothing to mine PoB on both chains and if you dont then you run the risk that you pick the wrong chain and lose the opportunity to have rewards for the time that consensus is being determined. Is this correct, if so what can be done to incentivize PoB minters to pick one chain?
|
|
|
|
|
I consider it a good thing that they are being developed and that most are failing. If one succeeds then it must offer something better than what bitcoin provides or it must offer something that bitcoin doesn't. The ones that fail prove that bitcoin is competitive. That doesn't mean that bitcoin will fail if one or more alt coins succeed since there is a huge market for these currencies to grow into. It also means there is some place for miners to go when they are out hashed by ASICs.
|
|
|
|
|
A client that starts off as a trusting thin client then migrates to using a pruned database then catches up by downloading the whole blockchain would be nice.
|
|
|
|
|
Posting to get my post count up so I can post a question where it would be read by who I want it to be read by. Hi.
|
|
|
|
It is to keep bots away from this site.
I'd pay a small bond (BTC) to skip the restrictions even if it meant loosing it if I turn out to be a bot. |
|
|
|
|
