It would be really fantastic to see the upper bound limits removed someday, perhaps.
We simply need moar primespersec (network has power) i.e. more folks mining and/or better miners / ASICs etc.,
I don't believe that the upper bound on shift value is a blocking issue. Back in Dec 2017, YomKi articulated why: There are a few different methods being used for current gap finding efforts: - Exhaustive search. This is looking for true record gaps, which means it started at 2 and went up from there. It's intensely computationally expensive. Tomás Oliveira e Silva ran a distributed project from 2005 to 2012 that got to 4e18 using years of work on hundreds of cores. Interestingly, the computational result was used in Helfgott's 2013 proof of the Odd Goldbach Conjecture. Recently the PGS team at mersenneforum have used a different method to extend this and after about 9 months have brought this to 10e18. The number of records per computational effort is very small, however these are true Minimal Gaps -- once found the record is permanent, as no earlier gaps of that size exist.
- Gapcoin. For relatively small P1 values (84-347 digits), choose a random small range, sieve out small multiples, then run Fermat tests to find gaps. While each step is efficient and fast, it's rather inefficient at finding record gaps. It's basically rapidly throwing darts while blindfolded and being spun around -- the only way to get more darts in the target is to throw faster.
- Primorial methods. Gaps are far more common at multiples of primorials without some small divisors, e.g. numbers of the form N * p# / k with k a small square free number. So if one looks at increasing values of N * 191#/30, for instance, using efficient methods for finding the previous and next primes around that point, one can find record gaps many times times faster than the gapcoin method. That is the method used by most other searchers and is what holds all but 3 of the highest merits (those three being from the exhaustive search). There are some minor variations -- Hans Rosenthal in 2017 did searches with a fixed large N and instead varied k. Using the dart analogy from before, this is throwing darts while aiming at the target. The darts are thrown a lot slower, but since they're all thrown in the direction of the target rather than randomly around the room, more of them result in high results.
I find it worth bearing in mind that the Gapcoin code is performing not one but two functions - the discovery of prime gaps with record merit is a designed side-effect of using prime gap search as as a proof-of-work mechanism for a cryptocurrency and that dual functioning requirement necessarily restricts the range of P1 values that can be selected. As I noted, the higher the shift, the larger the primes being sieved and so the lower the hash rate. More efficient primorial-based methods for finding gaps are an ill fit with the requirement to act as a proof-of-work mechanism. The Prime Gap Search group of the mersenne forum has an open source primorial-based gap search implementation but, given its functional focus is on searching gaps, it's not a good solution for a proof-of-work implementation. The fact that the Gapcoin prime gap record search implementation isn't as efficient as a dedicated approach is an inevitable trade-off arising from its use as a proof-of-work mechanism. Baisically, it's a balance and emphasising one aspect of this dual-functioning comes at the expense of the other. Also, PM'd to BitcoinFX ... I hope to finish this upgrade of Gapcoin to 0.16.3 in time to coincide with your announcement schedule:  Although most of the work is done and it syncs with both mainnet and testnet, it's unreleased because I have yet to get all the tests passing and it's unmentioned publicly because of its capacity to create bech32 txs which 0.9 clients can't handle and which might result in blockchain seizure. Also, I haven't ported the miner - which uses the old and no-longer-supported getwork RPC call - nor have I had time even to test my back-ported implementation of getwork (a potential but unlikely-to-succeed fallback attempt). You see, 0.16.3 is a bit old as a target for an upgrade, 0.20 would be better, 0.19.1 a minimum. I'm working on it. Cheers Graham |
|
|
|
Because I suspect that folks believe that sticking, syncing wallets are a Slimcoin-only problem, it's not, it's in Slimcoin's Peercoin heritage. This from the peercoin forum back on April 15th this year in response to someone reporting a wallet sticking while syncing: Make sure you don't unlock your wallet for minting until it has finished syncing. If that doesn't work, make sure you still have the wallet backup and delete the whole folder, open the client fresh and wait for it to sync from scratch, then replace the wallet.dat file and open with the -rescan tag.
And that's a Peercoin 0.8 Core 0.16 wallet that's sticking while syncing because of premature staking. I came across the post when confirming that the upgrade from Peercoin 0.7 to 0.8 was a hard fork ( 0.8 Peercoin hardfork task list), something that I think might be a bit of an organisation problem for Slimcoin, given the relatively large number of active addresses of uncontactable SLM hodlers. Cheers Graham |
|
|
|
... and it's worth noting that the current record for the largest prime gap with best merit is still held by Gapcoin with a (n inferred, from "87-digit prime") shift of 30
For the record, two gaps with highest merits on GapCoin blockchain so far have been found with a shift of 32, but there is nothing magical or clandestine about 32 here! I stand corrected (I did acknowledge that it was a rough-and-ready relationship). Dunno why I didn't check before I posted ... fwiw, this is how to use sqlitebrowser to obtain the figures from the "data" table (in the sqlite3 database to which I posted a link above).  The "gaps" table is the same one used by Seth Troisi in his post to the prime gap search group of the mersenneforum, he used select year, max(merit) from gaps group by year; to get the table he posted to the group: https://www.mersenneforum.org/showpost.php?p=536596&postcount=115Cheers Graham |
|
|
|
I have a question: how many testnet clients you are able to fit in a single VPS with 2GB? Does the resource need to run a testnet client is more power-hungry than when you just running it as a simple node.
Dunno for sure, don't have a 2Gb VPS to check it on, most of the RAM usage will be the db index which at 2.1 million blocks is probably a bit heavy, staking large bags is also compute-intensive and probably demands RAM to suit. Testnet otoh has 0 blocks (there isn't a legacy testnet chain to preserve atm) so will consume far fewer resources. I'll make a guess at two nodes at least, maybe the full four. Cheers Graham |
|
|
|
Do we have any testnet node available or running at the moment?
144.76.118.44 Cheers Graham |
|
|
|
FYI: a table showing a rough-and-ready relationship between the shift setting and the number of digits in the primes tested (data taken from the publicly-accessible gapdata.sqlite3.zip SQLite3 database file here on mega.nz). | Shift | Primedigits | | 16 | 82 | | 17 | 83 | | 18 | 83 | | 19 | 83 | | 20 | 84 | | 21 | 84 | | 22 | 84 | | 23 | 84 | | 24 | 85 | | 25 | 85 | | 26 | 85 | | 27 | 86 | | 28 | 86 | | 30 | 87 | | 31 | 87 | | 32 | 87 | | 34 | 88 | | 35 | 88 | | 36 | 88 | | 37 | 88 | | 37 | 89 | | 39 | 89 | | 40 | 90 | | 41 | 90 | | 42 | 90 | | 43 | 90 | | 45 | 91 | | 46 | 91 | | 47 | 92 | | 48 | 92 | | 49 | 92 | | 50 | 93 | | 50 | 92 | | 55 | 94 | | 57 | 95 | | 57 | 94 | | 58 | 95 | | 60 | 95 | | 60 | 96 | | 63 | 96 | | 63 | 97 | | 64 | 97 | | 69 | 98 | | 72 | 99 | | 74 | 100 | | 75 | 100 | | 88 | 104 | | 90 | 105 | | 95 | 106 | | 96 | 106 | | 100 | 107 | | 100 | 108 | | 105 | 109 | | 110 | 111 | | 112 | 111 | | 115 | 112 | | 120 | 114 | | 120 | 114 | | 121 | 114 | | 122 | 114 | | 123 | 114 | | 123 | 115 | | 125 | 115 | | 126 | 115 | | 127 | 116 | | 128 | 116 | | 130 | 116 | | 132 | 117 | | 144 | 121 | | 150 | 122 | | 150 | 123 | | 156 | 124 | | 180 | 132 | | 187 | 134 | | 188 | 134 | | 189 | 134 | | 190 | 135 | | 191 | 135 | | 192 | 135 | | 200 | 138 | | 225 | 145 | | 250 | 153 | | 255 | 154 | | 256 | 154 | | 256 | 155 | | 286 | 164 | | 300 | 168 | | 301 | 168 | | 308 | 170 | | 328 | 176 | | 330 | 177 | | 348 | 182 | | 350 | 183 | | 351 | 183 | | 356 | 185 | | 360 | 186 | | 380 | 192 | | 381 | 192 | | 382 | 192 | | 383 | 193 | | 391 | 195 | | 392 | 195 | | 392 | 196 | | 404 | 199 | | 409 | 200 | | 409 | 201 | | 412 | 201 | | 412 | 202 | | 414 | 202 | | 415 | 202 | | 416 | 203 | | 437 | 209 | | 440 | 210 | | 441 | 210 | | 442 | 210 | | 442 | 211 | | 443 | 211 | | 444 | 211 | | 445 | 212 | | 446 | 212 | | 447 | 212 | | 448 | 212 | | 449 | 213 | | 450 | 213 | | 451 | 213 | | 468 | 218 | | 472 | 219 | | 472 | 220 | | 473 | 220 | | 474 | 220 | | 476 | 221 | | 477 | 221 | | 478 | 221 | | 479 | 222 | | 480 | 222 | | 481 | 222 | | 482 | 223 | | 483 | 223 | | 502 | 229 | | 504 | 229 | | 506 | 230 | | 508 | 230 | | 509 | 231 | | 510 | 231 | | 511 | 231 | | 512 | 232 | | 540 | 240 | | 541 | 240 | | 542 | 241 | | 543 | 241 | | 544 | 241 | | 546 | 242 | | 547 | 242 | | 574 | 250 | | 576 | 251 | | 602 | 259 | | 607 | 260 | | 608 | 260 | | 608 | 261 | | 630 | 267 | | 634 | 268 | | 640 | 270 | | 698 | 287 | | 699 | 288 | | 700 | 288 | | 702 | 289 | | 720 | 294 | | 732 | 298 | | 760 | 306 | | 762 | 307 | | 764 | 307 | | 764 | 308 | | 765 | 308 | | 767 | 308 | | 790 | 315 | | 794 | 316 | | 794 | 317 | | 797 | 317 | | 798 | 318 | | 799 | 318 | | 828 | 327 | | 829 | 327 | | 830 | 327 | | 831 | 327 | | 831 | 328 | | 832 | 328 | | 860 | 336 | | 888 | 345 | | 896 | 347 | | 920 | 354 | | 920 | 355 | | 986 | 374 | | 987 | 375 | | 988 | 375 | | 991 | 376 | | 992 | 376 | | 1010 | 381 | | 1011 | 382 | | 1012 | 382 | | 1014 | 383 | | 1017 | 383 | | 1019 | 384 | | 1020 | 384 | | 1020 | 385 | | 1021 | 385 | | 1022 | 385 | | 1023 | 385 | | 1023 | 386 | | 1024 | 386 |
(I've found that the higher the shift setting, the lower the hashrate, unsurprising). Gapcoin maxes out (nominally) at a shift of 1024 ( as set by Jonny Frey, to avoid DoS) with a max prime digit length of 386, around number 10000 of 95000 in a sorted list of primedigit lengths taken from the prime gaps list (where the extreme upper regions see prime digit lengths of 100,000-200,000). However, the criterion is maximum known merit and gap size, not the number of digits in the prime and it's worth noting that the current record for the largest prime gap with best merit is still held by Gapcoin with a(n inferred, from "87-digit prime") shift of 30: NEW PRIME GAP OF MAXIMUM KNOWN MERIT
The Gapcoin network (Jonnie Frey, developer), a Bitcoin derivative which employs a hashing algorithm to search for prime gaps of high merit, has discovered a new prime gap of maximum known merit, a gap of G=8350 following the 87-digit prime P1=293703234068022590158723766104419463425709075574811762098588798217895728858676728143227. The merit M=G/ln(P1) of this gap is M=41.93878373153988, the largest merit of any known prime gap, and the first prime gap to be discovered with a merit exceeding 40. The endpoints of the gap have been certified as primes deterministically, using the Akiyama-Kida-O'Hara UBASIC implementation (1988-1992) of the APRCL2 test, due to Adleman, Pomerance, Rumely, Cohen, H. W. Lenstra, and A. K. Lenstra (1984-1987).
Cheers Graham |
|
|
|
In my understanding you can do the same thing on a VPS, and from the point of view of that VPS it will be still a local testchain, or?
Local to the VPS, yes - that's entailed in the connect=127.0.0.1:<port> configuration statements. Cheers Graham |
|
|
|
Maybe you have a VPS with 4 GB of Ram, or are you speaking about your local computer?
Hint: a neat little local testnet chain to play with.
Because slimcoind is using almost all the RAM on my 1GB Ram VPSs.
On testnet? Something horribly wrong there. But be that as it may, in general a 1Gb VPS is too under-powered for altcoin development. Cheers Graham |
|
|
|
Do we have any testnet node available or running at the moment?
The developer asked me to create at least 4 nodes for the testnet for its work. I have some node available, but before I distract all the 4 from the main net I'm asking, just in case.
That's a bit ... unusual. IME, such a network is trivial to set up on single m/c, all that's required is that each node has its own datadir and is configured with a different port number (with port= and rpcport=). I approach this by having (say) 4 different datadir directories (typically datadir-a, datadir-b and so on) each with its own slimcoin.conf setting the ports (typically to, 60000/60001, 60002/60003, and so on) cross-connected (with port=60000,connect=128.0.0.1:60002 and port=60002,connect=128.0.0.1:60000 and so on) and run the clients with -datadir=`pwd`/datadir-a, -datadir=`pwd`/datadir-b, etc. I find this arrangement very handy for experimentation as I can trivially start/stop the clients and clear out the datadirs after each experiment with a couple of simple bash commands. For anyone who may be interested in running their own local Slimcoin testnet network, create the four datadir-? dirctories and add a slimcoin.conf to each: basic slimcoin.conf: testnet=1
reservebalance=0.00
debug=1
listen=1
server=1
txindex=1
fastindex=1
genproclimit=2
gen=0
printcreation=0
printstakemodifier=0
printselectcoin=0
rpcuser=slimcoinrpcuser
rpcpassword=slimcoinrpcuser
rpcallowip=127.0.0.1
maxconnections=3
upnp=0
added to the basic slimcoin.conf for datadir-a: port=60000
rpcport=60001
connect=128.0.0.1:60002
connect=128.0.0.1:60004
connect=128.0.0.1:60006
added to the basic slimcoin.conf for datadir-b: port=60002
rpcport=60003
connect=128.0.0.1:60000
connect=128.0.0.1:60004
connect=128.0.0.1:60006
added to the basic slimcoin.conf for datadir-c: port=60004
rpcport=60005
connect=128.0.0.1:60000
connect=128.0.0.1:60002
connect=128.0.0.1:60006
added to the basic slimcoin.conf for datadir-d: port=60006
rpcport=60007
connect=128.0.0.1:60000
connect=128.0.0.1:60002
connect=128.0.0.1:60004
Then just start 4 clients, the first with -datadir=`pwd`/datadir-a, the second with -datadir=`pwd`/datadir-b and so on, and you've got yourself a neat little local testnet chain to play with. Just sayin' Cheers Graham |
|
|
|
Basically, this means these switches can be deleted completely? I've looked a bit into the code but I lack proper understanding what changes in the Peercoin protocol they're referring to.  Yes, pretty much so, they pertain to serial changes to the Peercoin ledger contents, tx validations/limits/fees mainly, so will be irrelevant to the Slimcoin ledger legacy. Cheers Graham |
|
|
|
The developer is suggesting us to make the upgrade directly to PPC v.0.10, what do you think?
Sensible suggestion. Not only is the new PoSTemperature mechanism worth having but migrating to an older version of PPC would be suboptimal - basically kicking the can down the road - because an eventual upgrade to PPC v10 is inevitable, surely? Cheers Graham |
|
|
|
The developer has reached the first step we've agreed with him upon and released the document in which he is analyzing SLM code. Please let me know what do you think. Here is the document. It seems Slimcolin derived from Peercoin v0.4.0ppc and partially patched from v0.5Xppc.
Slimcoin is originally derived from Peercoin 3.0, here is the specific repos commit from which it was cloned: https://github.com/peercoin/peercoin/tree/154b52acaad8acb37a6f5e6f107ce0bfeca68229, as evidenced here: https://github.com/slimcoin/slimcoin/blob/master/src/version.cpp#L39Protocol switch time ... These values are using to check whether the given transaction is subject to the specified protocol.
This is Peercoin-only code and refers to switches in Peercoin protocol for 0.4/0.5, these were changes not considered appropriate for Slimcoin but the switch was retained in case the community changed its collective mind on the relevance of the changes. One change that doesn't seem to have been covered is the addition of running totals of moneysupply and totalburnt to the index - https://github.com/slimcoin-project/Slimcoin/commit/43e7af0a84f419ab1a1168189f95e193bb26be7#diff-e8db9b851adc2422aadfffca88f14c91 (something of a scrappy commit but I was still getting to grips with it all at that point) - this was implemented to satisfy exchange requirements of the time. The RPC commands dumpbootstrap, linearizehashes, getinscription, importpassphrase, encryptmessage, decryptmessage, encryptdata, decryptdata and makekeypair were all added by me and are not relevant to Slimcoin core functionality, the same holds true for the GUI additions of block browser, chat window, mining page and inscription page. fwiw, I made a diff of the first changes: diff -uNr peercoin-0.3.2/src/base58.h slimcoin-0.3.2/src/base58.h
--- peercoin-0.3.2/src/base58.h 2020-04-10 16:58:34.017203905 +0100
+++ slimcoin-0.3.2/src/base58.h 2020-04-19 10:56:57.319392515 +0100
@@ -264,8 +264,8 @@
public:
enum
{
- PUBKEY_ADDRESS = 55, // ppcoin: addresses begin with 'P'
- SCRIPT_ADDRESS = 117, // ppcoin: addresses begin with 'p'
+ PUBKEY_ADDRESS = 63, // slimcoin: addresses begin with 'S'
+ SCRIPT_ADDRESS = 125, // slimcoin: addresses begin with 's'
PUBKEY_ADDRESS_TEST = 111,
SCRIPT_ADDRESS_TEST = 196,
};
diff -uNr peercoin-0.3.2/src/main.cpp slimcoin-0.3.2/src/main.cpp
--- peercoin-0.3.2/src/main.cpp 2020-04-19 11:31:32.605751015 +0100
+++ slimcoin-0.3.2/src/main.cpp 2020-04-19 12:04:09.529593253 +0100
@@ -868,8 +868,8 @@
return nSubsidy;
}
-static const int64 nTargetTimespan = 7 * 24 * 60 * 60; // one week
-static const int64 nTargetSpacingWorkMax = 12 * STAKE_TARGET_SPACING; // 2-hour
+static const int64 nTargetTimespan = 30 * 60; // retargets every 30 minutes
+static const int64 nTargetSpacingWorkMax = 10 * STAKE_TARGET_SPACING; // 15 minutes
//
// minimum amount of work that could possibly be required nTime after
@@ -2241,9 +2241,9 @@
// vMerkleTree: 4a5e1e
// Genesis block
- const char* pszTimestamp = "Matonis 07-AUG-2012 Parallel Currencies And The Roadmap To Monetary Freedom";
+ const char* pszTimestamp = "RT: Non-denying denial? RSA aims to distance itself from NSA scandal";
CTransaction txNew;
- txNew.nTime = 1345083810;
+ txNew.nTime = 1388098028;
txNew.vin.resize(1);
txNew.vout.resize(1);
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(9999) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
@@ -2259,15 +2259,15 @@
if (fTestNet)
{
- block.nTime = 1345090000;
- block.nNonce = 122894938;
+ block.nTime = 1388098028;
+ block.nNonce = 865766467;
}
//// debug print
printf("%s\n", block.GetHash().ToString().c_str());
printf("%s\n", hashGenesisBlock.ToString().c_str());
printf("%s\n", block.hashMerkleRoot.ToString().c_str());
- assert(block.hashMerkleRoot == uint256("0x3c2d8f85fab4d17aac558cc648a1a58acff0de6deb890c29985690052c5993c2"));
+ assert(block.hashMerkleRoot == uint256("0x6561fdf42da044631a835cad31128929d8b95fde6ce3e4f89cff8d710d8af927"));
block.print();
assert(block.GetHash() == hashGenesisBlock);
assert(block.CheckBlock());
diff -uNr peercoin-0.3.2/src/main.h slimcoin-0.3.2/src/main.h
--- peercoin-0.3.2/src/main.h 2020-04-19 11:09:01.953785469 +0100
+++ slimcoin-0.3.2/src/main.h 2020-04-19 11:35:48.904010014 +0100
@@ -41,7 +41,7 @@
static const int COINBASE_MATURITY = 500;
// Threshold for nLockTime: below this value it is interpreted as block number, otherwise as UNIX timestamp.
static const int LOCKTIME_THRESHOLD = 500000000; // Tue Nov 5 00:53:20 1985 UTC
-static const int STAKE_TARGET_SPACING = 10 * 60; // 10-minute block spacing
+static const int STAKE_TARGET_SPACING = 90; // 90 second block spacing
static const int STAKE_MIN_AGE = 60 * 60 * 24 * 30; // minimum age for coin age
static const int STAKE_MAX_AGE = 60 * 60 * 24 * 90; // stake age of full weight
@@ -52,7 +52,7 @@
#endif
static const uint256 hashGenesisBlockOfficial("0x0000000032fe677166d54963b62a4677d8957e87c508eaa4fd7eb1c880cd27e3");
-static const uint256 hashGenesisBlockTestNet("0x00000001f757bb737f6596503e17cd17b0658ce630cc727c0cca81aec47c9f06");
+static const uint256 hashGenesisBlockTestNet("0x0000000a8ecef22cc3af763a952750f70c958e7812b4df332a13ea18aa478bb1");
static const int64 nMaxClockDrift = 2 * 60 * 60; // two hours
@@ -586,7 +586,7 @@
{
// Large (in bytes) low-priority (new, small-coin) transactions
// need a fee.
- return dPriority > COIN * 144 / 250;
+ return dPriority > COIN * 960 / 250; //960 blocks per day
}
int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=false, enum GetMinFee_mode mode=GMF_BLOCK) const
diff -uNr peercoin-0.3.2/src/protocol.cpp slimcoin-0.3.2/src/protocol.cpp
--- peercoin-0.3.2/src/protocol.cpp 2020-04-19 11:40:42.762597925 +0100
+++ slimcoin-0.3.2/src/protocol.cpp 2020-04-19 11:40:39.782571688 +0100
@@ -17,14 +17,14 @@
// Public testnet message start
// unsigned char pchMessageStartTestBitcoin[4] = { 0xfa, 0xbf, 0xb5, 0xda };
-static unsigned char pchMessageStartTestOld[4] = { 0xdb, 0xe1, 0xf2, 0xf6 };
-static unsigned char pchMessageStartTestNew[4] = { 0xcb, 0xf2, 0xc0, 0xef };
-static unsigned int nMessageStartTestSwitchTime = 1346200000;
+static unsigned char pchMessageStartTestOld[4] = { 0xbd, 0x1e, 0x2f, 0xa3 };
+static unsigned char pchMessageStartTestNew[4] = { 0x4d, 0x2a, 0xe1, 0xab };
+static unsigned int nMessageStartTestSwitchTime = 1389000000;
// Message start (switch from Bitcoin's in v0.2)
-static unsigned char pchMessageStartBitcoin[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
-static unsigned char pchMessageStartCoin[4] = { 0xe6, 0xe8, 0xe9, 0xe5 };
-static unsigned int nMessageStartSwitchTime = 1347300000;
+static unsigned char pchMessageStartBitcoin[4] = { 0x9f, 0xeb, 0x1b, 0x8a };
+static unsigned char pchMessageStartCoin[4] = { 0x6e, 0x8b, 0x92, 0xa5 };
+static unsigned int nMessageStartSwitchTime = 1400000000;
void GetMessageStart(unsigned char pchMessageStart[], bool fPersistent)
{
diff -uNr peercoin-0.3.2/src/protocol.h slimcoin-0.3.2/src/protocol.h
--- peercoin-0.3.2/src/protocol.h 2020-04-19 11:41:10.118838763 +0100
+++ slimcoin-0.3.2/src/protocol.h 2020-04-19 11:41:12.642860983 +0100
@@ -15,9 +15,9 @@
#include <string>
#include "uint256.h"
-#define COIN_PORT 9901
-#define RPC_PORT 9902
-#define TESTNET_PORT 9903
+#define COIN_PORT 41682
+#define RPC_PORT 41683
+#define TESTNET_PORT 41684
extern bool fTestNet;
diff -uNr peercoin-0.3.2/src/version.cpp slimcoin-0.3.2/src/version.cpp
--- peercoin-0.3.2/src/version.cpp 2020-04-10 16:58:34.033204087 +0100
+++ slimcoin-0.3.2/src/version.cpp 2020-04-19 11:47:33.806259732 +0100
@@ -33,9 +33,10 @@
# include "build.h"
#endif
-// git will put "#define GIT_ARCHIVE 1" on the next line inside archives. $Format:%n#define GIT_ARCHIVE 1$
+// git will put "#define GIT_ARCHIVE 1" on the next line inside archives.
+#define GIT_ARCHIVE 1
#ifdef GIT_ARCHIVE
-# define GIT_COMMIT_ID "$Format:%h$"
+# define GIT_COMMIT_ID "154b52a"
# define GIT_COMMIT_DATE "$Format:%cD"
#endif
Cheers Graham |
|
|
|
I remember Freicoin, and I remember spending quite a while trying to figure out the logic of some long word he used to explain something about interest rates and a fair distribution of money based on something confusing about the working class or something. I respect somebody who has political beliefs but it seemed to be a well intentioned shitcoin. The rest of your first paragraph says what I said while claiming to refute it.
tbh, I don't find this kind of btc convo at all rewarding. You say you struggled with the concept of demurrage ( https://en.wikipedia.org/wiki/Demurrage_%28currency%29) and how it pertains to Freicoin ( http://freico.in/), I can't really help you there other than to suggest that perhaps you might refrain from ungrounded opining (either disparagingly or encouragingly) on things that you don't understand.. Freiexchange was created to unload or create liquidity for bags.
Your negative attitude epitomises the point I made about operating a cryptocurrency exchange being a thankless effort. The technical aspects of operating a cryptocurrency exchange are most unlikely to interest someone with technical skills, rather the opposite. It'd basically be a labour of love, maintained in the face of countless kneejerk disparagements from people with very little skin in the game. As far as definition of good coin vs shitcoin.
A very high quality coin will have a very slow emission with no premine, ico etc, it should be a productive algorithm that does something with its hashing power, etc.
Your rephrasing of my challenge casually elided the key aspect - a practical definition. Unfortunately, "productive" and "does something with its hashing power" are dismally vague failures in that respect. Some few coins attract a completely different type of person. A lot of people mine gap coin because they feel like it is accomplishing something. Lots of people lent their computers to BOINC and similar projects before Gridcoin, and getting that coin to sell isn’t their main motive.
Those are confident statements but unfortunately are either based on zero evidence or fly in the face of any existing evidence (Gapcoin has 17 known nodes according to chainz, out of that slight population, where'd you get the idea that "a lot of people mine gap coin"? I'm disinclined to devote effort to disabusing you of your misperceptions and ungrounded opinions because you don't seem to have put in any significant effort in forming them. As for your being sorry you have to tell me my notions about ai are fanciful, are you able to articulate something specific? I get that you are trying to minimize or counter my statements about ai, but if you actually do have a better knowledge on the subject then try to put into words what it is you disagree with.
Your ungrounded opinion is too unformed to merit or facilitate any more specific rebuttal. There isn't much one can sensibly respond to such hand-waviness as "Once ai science coins developed which produced a valuable commodity i.e., math or science discovery," Your statements clearly advertise that you have little or no knowledge of the underpinning "ai" technology being touted so you are unfortunately in the position of basically shilling for the next generation of shitcoins, ironic as that may seem. I have no idea what all the options are but I’m sure a lot of technical people could figure it out.
Nor do you have any idea of how much work is involved in that figuring out, yet that doesn't seem to inhibit you from pontificating on how it'd be a good thing. Take the hint - it's not quite the no-brainer that it might seem. One last point about ‘decent coins’ vs ‘shit coins’, then I’ll drop this as there doesn’t seem to be interest.
Promises, promises  But yes, let's call it a day, it's not exactly a productive discussion. Cheers Graham |
|
|
|
Freiexchange I’ve watched for a while, probably traded there in the past. It’s a good exchange, useful, well made like freebitcoins, etc. But it’s purpose is to unload or create liquidity for bags. Your assessment of purpose is off the mark. Fedde was quite explicit about his original motivation, that of providing an exchange for the otherwise-untradable Freicoin - hence the name of the exchange. Since then he has been variously amenable to other altcoins in a similar position regards lack of listing and was kind enough to respond positively to my pleas to add (firstly) SLM and (secondly) DTC. There seems to be something of a contradiction in your argument - "the financial part is a function of its success" yet "it’s purpose is to unload or create liquidity for bags". Isn't this how it inevitably works? What's missing here is a practically useful definition of the distinction between "ethically created useful coins" and "a lot of shitcoins" and not just personal opinion. Establishing and operating a cryptocurrency exchange is exactly that - "operating". It obviously does not necessarily require the owner/operator to possess technical skills, merely the ability to commission others to deploy them. BTW, your notions about AI and its possible role in cryptocurrency are rather fanciful, I'm sorry to have to tell you. Cheers Graham |
|
|
|
It’s a good idea if somebody does it right. It has to be done by a person who has technical skills and likes math coins etc
The core problem is that setting up and running a crypto exchange is a security nightmare, is extremely time-consuming and is largely thankless (both socially and financially). The upshot of this is that the whole idea is quite unattractive to someone with technical skills and who likes math coins. AFAICT, Freebitcoins and Freiexchange are the closest realisations of your concept, the former has been introduced upthread in Bayareacoins' own words, the latter was originally created to provide a market for Freicoin, subsequently expanded modestly (in cryptoexchange terms) and continues to concentrate on providing an exchange service to many, if not most, continuing vintage altcoins. Cheers Graham |
|
|
|
I agree here, I've also thought about it before and don't care for making some dubious hacked exchange account rich, especially while they contribute nothing and do not engage at all with the community. We'll have to see about what kind of a solution would make sense, maybe a vote perhaps. It's good to have this discussion.
One approach is to edit the UTXO to exclude the offending addy and reassign the balance to a community-owned multi-sig address for use thereafter as a community Treasury. Cheers Graham |
|
|
|
Thanks for your explanations. So I interpret basically you would recommend to first port the modern Bitcoin code (or better, PPC 0.8+) to Slimcoin, and then add the watchonly address functionality and the peerassets-based tokens.
Ah, I see from a later post that you do have the right model. Cheers Graham |
|
|
|
So, I've had to recourse to the other option, bringing the (more complete) earlier branch up to date. In addition, the earlier branch included caching of watched address values, something that's going to be functionally vital.
Cool, thank you for that. I've downloaded your new additions but they don't compile on my machine (Debian 11), are your editions ready for testing or should I wait a bit more? Unfortunately ... I have been reluctantly forced to admit to myself that it's not really feasible to add watchonly address functionality to Slimcoin in a sufficiently robust and reliable enough implementation for DeFi use. The watchonly address functionality in Peercoin is there by virtue of Sunny King's later merge of Bitcoin 0.8.6. It's not a Peercoin-specific addition, it was inherited via that merge which occurred a substantial period of time after the 2014 Slimcoin fork of PPCoin. It's not that watchonly addresses can't be hacked into Slimcoin after a fashion, the problem is that the functionality would then have been hacked into Slimcoin. The extended isMine functionality didn't even have a solid test suite until Sep 2017 https://github.com/bitcoin/bitcoin/commit/7a1e873b27b790c965d9927ecd465710dc103136#diff-f70eb687f49d254115fb55bce1c23a1c and by that time, the architecture of the Bitcoin codebase had changed substantially, with the script-handling code having been split off into a separate directory and reorganised into subprocessing components (hence the first change in that diff is to src/script/ismine.cpp). It's not something I'd want either to guarantee or to provide long-term support for and, from a practical perspective, PeerAssets would have to have a robust, reliable underpinning implementation with solid support. I guess that's something related to boost-iostreams, I have installed Boost version 1.71 (including -dev). I saw support for Boost 1.70+ was your last commit, so it may be related to that.
Yes, it's a Boost 1.71 thing. I have a fix. Cheers Graham |
|
|
|
This weekend I'll have a bit of time so I can again fire up your watchaddress version
Not worth it. I had a choice between bringing the original branch up to the latest code or re-doing the additions using the latest code as a base. I chose the latter course and was wrong. Whilst it did work for me, watched addresses are indistinguishable from owned addresses in the GUI which is unfortunately unacceptable. So, I've had to recourse to the other option, bringing the (more complete) earlier branch up to date. In addition, the earlier branch included caching of watched address values, something that's going to be functionally vital. Cheers Graham |
|
|
|
|
Show Posts
