Bitcoin Forum
May 26, 2024, 03:20:34 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 [115] 116 117 118 119 120 121 122 123 124 »
  Print  
Author Topic: [ANN][GAP] Gapcoin - Prime Gap Search - New Math Algo - CPU / GPU - Zero Premine  (Read 286861 times)
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 01, 2021, 02:47:29 PM
Last edit: March 01, 2021, 05:02:39 PM by gjhiggins
 #2281

Wizz_^ has been busy with Powershell, creating plots of Gapminer performance. I'm following along at my own pace using Python to configure systematically the miner parameters, start/stop the miner and record the results.

I wrote up some interim notes on my understanding of what changing the settings of the shift parameter means in terms of prime digit length and Gapminer performance and have published them as a standalone HTML page on Mega: https://mega.nz/file/6VUAXLhC#JWC-5OxsZonQ1q0oHlDbqQ2OtAHjWcwbUHUhUgxQ0QM (download and open in browser) got it badly wrong. Will repost in due course.

Cheers

Graham
M0ndialu
Hero Member
*****
Offline Offline

Activity: 819
Merit: 1000



View Profile WWW
March 01, 2021, 07:48:25 PM
 #2282

i try to send 297 gap from new wallet to exchange and give me this

https://chainz.cryptoid.info/gap/tx.dws?c5deecc8a5a606408f00549058c48cf9720827bdfa576f56a6290552d959b785.htm

Not yet redeemed   OP_RETURN..  Huh

gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 01, 2021, 09:18:30 PM
Last edit: July 05, 2021, 11:58:15 PM by Welsh
 #2283

Mod note: consecutive posts merged

i try to send 297 gap from new wallet to exchange and give me this

https://chainz.cryptoid.info/gap/tx.dws?c5deecc8a5a606408f00549058c48cf9720827bdfa576f56a6290552d959b785.htm

Not yet redeemed   OP_RETURN..  Huh
That's not good. I'll investigate. The client may have inappropriately included what should be placeholder text. If so, I'll reimburse your Gapcoin.

Cheers

Graham

i try to send 297 gap from new wallet to exchange and give me this
https://chainz.cryptoid.info/gap/tx.dws?c5deecc8a5a606408f00549058c48cf9720827bdfa576f56a6290552d959b785.htm
Not yet redeemed   OP_RETURN..  Huh
That's not good. I'll investigate. The client may have inappropriately included what should be placeholder text. If so, I'll reimburse your Gapcoin.
Your apparent disinclination to provide details isn't helpful.

I can't immediately replicate the issue you encountered, there was no issue with the standard 1 GAP tx I sent to freiexchange https://chainz.cryptoid.info/gap/tx.dws?979fbb27e9a31d00e0ba4e395e65037db1b865d0bc61cf00806734584774670e.htm.

Ordinarily, I would enquire whether the common precaution of you sending an initial test low-value deposit of 0.5 GAP was successful but I doubt you did that.

Given that a standard transaction succeeded, it would appear that the Inscription/Notarisation UI isn't as idiot-proof as I hoped, so I will have to suppress that particular feature. I'll make new binaries available in a few hours.

PM me a Gapcoin address and I'll reimburse your 297 GAP.

Cheers

Graham

M0ndialu
Hero Member
*****
Offline Offline

Activity: 819
Merit: 1000



View Profile WWW
March 01, 2021, 11:29:46 PM
 #2284

not all time sent work bad, sometimes it worked good  Huh

Good: https://chainz.cryptoid.info/gap/tx.dws?65e82dc94e412535b26c54435f7faf99d0b5b130c41d97afc8d27710e299b47d.htm

Bad: https://chainz.cryptoid.info/gap/tx.dws?507de7422cdec6c912fc64cffbcbf3a1991febca3dd246bcc5db33f84d9517d1.htm

gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 02, 2021, 04:05:10 AM
 #2285

Right. You should now wait until I fix it.

Cheers

Graham
UsernameNumber7
Member
**
Offline Offline

Activity: 256
Merit: 60


View Profile
March 02, 2021, 05:22:31 AM
 #2286

Thanks Higgins........it's too bad about Old Wallet not working with 16.3.   Is it easiest to transfer Coins into a new Wallet that is backed up? 

In 16.3 in-wallet mining seems to be working, no errors using 20 GB Memory.

Have not mined a block yet, but optimistic nothing will crash as it seems stable.  The previous error was quick to show up! 




https://www.TRISQUEL.INFO #1 Free Software Linux Operating  System

Trisquel OS "Just Do It"        "Sic Semper Tyranis"
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 02, 2021, 05:50:10 AM
Last edit: July 06, 2021, 12:00:25 AM by Welsh
 #2287

Mod note: consecutive posts merged

Is it easiest to transfer Coins into a new Wallet that is backed up?
You have a choice of hand-importing to the 0.16 client each of your 0.9-dumped privkeys or using the 0.9-dumpwallet/0.16-importwallet process to do it in one step. I can't see why it'd be any easier with a backed-up wallet but in any case, always back up the wallet before any significant admin, it's just good practice.

Thanks for the kind words, btw.

Cheers

Graham

You should now wait until I fix it.

Now fixed.

BitcoinFX's announcement caught me unawares somewhat as I hadn't taken the opportunity to go through the code in detail to ensure as best I could that all the work-in-progress was properly tidied up. In the event, I overlooked a stray line of developer-convenience code that, under a set of conditions that I apparently couldn't actually replicatet (although I glimpsed the fault briefly on one occasion) had the effect of inappropriately activating the inscription field placeholder text as though the user has pasted it in. I've removed the developer convenience but that was only part of the problem - the inscription/notarisation facility uses OP_RETURN data and any such transactions should only ever be send-to-self, which wasn't being enforced --- but it is now. I took some time to rework that section completely and now OP_RETURN transactions MUST have an amount of 0, that should prevent any more coins going astray via that route.

I've sent M0ndialu 500 GAP, to reimburse his loss and as a token bug bounty.

To avoid the possibility of losing coins, please refrain from making transactions with the 0.16.3 client until you've switched to the new binaries/source code pre-released as 0.1rc-beta: https://github.com/gjhiggins/gapcoin-core/releases/tag/v0.1rc-beta

Sorry for the convenience.

Cheers

Graham
BitcoinFX
Legendary
*
Offline Offline

Activity: 2646
Merit: 1720


https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF


View Profile WWW
March 02, 2021, 07:30:37 PM
Last edit: March 15, 2021, 10:53:08 AM by BitcoinFX
 #2288

I was not really aware that I had 'announced' anything as such, rather I posed some questions to the community with a possible upgrade schedule.

However, when an alpha Release Candidate is available for download, people often take it as read that they can safely 'upgrade', which is clearly not the case.

I did not add the windows alpha Release Candidate to https://gapcoin.club

The new core repository is made available as a link, in the hopes of attracting additional developers to assist Graham ...

"Linux Build - Gapcoin Core v0.16.3 - Work in progress - v0.16.3-rc-alpha"

Is there anyone here who can compile the Windows .EXE for Higgins New Wallet?

I adapted the Ravencoin build script - by replacing references to Ravencoin with references to Gapcoin. The resulting Windows64 binaries are here (and have previously been advertised as such):

hxxps://github.com/gjhiggins/gapcoin-core/releases/download/v0.1rc-alpha/gapcoin-0.16.3-win64-setup.exe

hxxps://github.com/gjhiggins/gapcoin-core/releases/download/v0.1rc-alpha/gapcoin-0.16.3-win64.zip

(I did see your HMAC PR for v0.9 but as you observe, it is an ill fit with the 0.16.3 codebase)

The 0.20 client will remain unreleased because the code in 0.16.3 that enables a soft-fork segwit transition has been removed in the Bitcoin 0.20 client. This is because the Bitcoin blockchain is now irrevocably segwit-enabled and the soft-fork code has been replaced by a simple height switch. Without this soft-fork transition code, upgrading to the 0.20 client would unfortunately necessitate a hard fork for the current Gapcoin chain AIUI and according to the chainz explorer, the overwhelming majority of Gapcoin nodes are Gapcoin 0.9.2 vintage, likely original Windows clients and there seems to be little likelihood of that changing.

Cheers

Graham


The Windows64 binary Release Candidate will be added to Gapcoin Club (with relevant advisories) if that is appropriate at this juncture?

...

It is no secret that Gapcoin Club has operated the majority of network listening nodes for a number of years now.

Whilst these servers are still currently running Gapcoin v0.9.2 they were successfully upgraded to v0.16.3 for a couple of weeks testing on mainnet.

The servers are also running Riecoin nodes, the respective Gapcoin on Tor .onion addnodes (several public Tor Bridges), as well as solo CPU mining some GAP!

- https://gapcoin.club/downloads/gapcoin.conf.tor.txt

N.B. All Tor v2 .onion's will cease to function on July 15th, 2021 as 0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

See: "Onion Service version 2 deprecation timeline"
- https://blog.torproject.org/v2-deprecation-timeline

Bitcoin Core v0.21 supports Tor v3 addresses more fully with BIP155 supporting gossiping them over the network.

Currently, a target date of July 15th, 2021 would also seem to be a reasonable time frame to notify users to upgrade their Gapcoin wallets to a newer Gapcoin Core Project release.

Gapcoin Club will continue to run and upgrade our existing nodes, whilst introducing and announcing new Gapcoin mainnet nodes (and hopefully v3 .onion compatible addnodes).

The majority of the existing servers will then be retired.

- https://gapcoin.club/downloads/gapcoin.conf

As the network regains its user base the club will shift focus to launching our mining pool, adding faster seednodes and establishing and running a block explorer.

Also see: https://bitcointalk.org/index.php?topic=822498.msg56186392#msg56186392

We have a Gapcoin testnet.

- https://bitcointalk.org/index.php?topic=822498.msg55546099#msg55546099

Please don't rush to 'upgrade' on mainnet, before any 'official' release announcements are made.

Graham is continuing to do sterling work in regards to development and I hope others will become more involved with helping as we progress.

"Bitcoin OG" 1JXFXUBGs2ZtEDAQMdZ3tkCKo38nT2XSEp | Bitcoin logo™ Enforcer? | Bitcoin is BTC | CSW is NOT Satoshi Nakamoto | I Mine BTC, LTC, ZEC, XMR and GAP | BTC on Tor addnodes Project | Media enquiries : Wu Ming | Enjoy The Money Machine | "You cannot compete with Open Source" and "Cryptography != Banana" | BSV and BCH are COUNTERFEIT.
M0ndialu
Hero Member
*****
Offline Offline

Activity: 819
Merit: 1000



View Profile WWW
March 02, 2021, 10:44:31 PM
 #2289

Thanks Graham!  Grin

what settings i need for all blocks found on solo mining go to one address for see my adress here https://chainz.cryptoid.info/gap/#!extraction

on this moment all block find go to random generate adress

UsernameNumber7
Member
**
Offline Offline

Activity: 256
Merit: 60


View Profile
March 02, 2021, 11:24:12 PM
 #2290



I think the 16.3 Wallet is good for trying to adopt.  I think you should promote it now BitcoinFX.  It's solid mining ect........


The importing addresses will only be harder for new people if they start using the old wallets when they should be using the New one and never have to worry about the import issues.

I wish there was a better way for the wallet import. 

But I think it's best to get it out of the way and deal with the issues as they come up.  Promoting the old wallets will just be negative to the overall goal of getting new people to use Gapcoin. 


https://www.TRISQUEL.INFO #1 Free Software Linux Operating  System

Trisquel OS "Just Do It"        "Sic Semper Tyranis"
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 03, 2021, 12:41:28 AM
 #2291

what settings i need for all blocks found on solo mining go to one address for see my adress here

on this moment all block find go to random generate adress
As I understand it, that's the way it's always been with the built-in miner, each block reward is credited to a newly-generated address (these days, actually a scriphash). Rewards credited to specifically-set addresses are feature of pool mining or solo mining with an external miner.

Cheers

Graham
BitcoinFX
Legendary
*
Offline Offline

Activity: 2646
Merit: 1720


https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF


View Profile WWW
March 03, 2021, 12:51:51 PM
 #2292

what settings i need for all blocks found on solo mining go to one address for see my adress here

on this moment all block find go to random generate adress
As I understand it, that's the way it's always been with the built-in miner, each block reward is credited to a newly-generated address (these days, actually a scriphash). Rewards credited to specifically-set addresses are feature of pool mining or solo mining with an external miner.

Cheers

Graham


Gapcoin Core v0.16.3 ...

cd gapcoin-core/src && ./gapcoin-cli help

Excerpt;
Quote
== Generating ==
generate nblocks ( maxtries )
generatetoaddress nblocks address (maxtries)
getgenerate
getwork ( "data" )
setgenerate generate ( genproclimit ) ( sievesize ) ( sieveprimes ) ( shift )

See:
- https://developer.bitcoin.org/reference/rpc/generatetoaddress.html

Grin

"Bitcoin OG" 1JXFXUBGs2ZtEDAQMdZ3tkCKo38nT2XSEp | Bitcoin logo™ Enforcer? | Bitcoin is BTC | CSW is NOT Satoshi Nakamoto | I Mine BTC, LTC, ZEC, XMR and GAP | BTC on Tor addnodes Project | Media enquiries : Wu Ming | Enjoy The Money Machine | "You cannot compete with Open Source" and "Cryptography != Banana" | BSV and BCH are COUNTERFEIT.
BitcoinFX
Legendary
*
Offline Offline

Activity: 2646
Merit: 1720


https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF


View Profile WWW
March 03, 2021, 01:02:13 PM
 #2293



I think the 16.3 Wallet is good for trying to adopt.  I think you should promote it now BitcoinFX.  It's solid mining ect........


The importing addresses will only be harder for new people if they start using the old wallets when they should be using the New one and never have to worry about the import issues.

I wish there was a better way for the wallet import. 

But I think it's best to get it out of the way and deal with the issues as they come up.  Promoting the old wallets will just be negative to the overall goal of getting new people to use Gapcoin. 


Whilst I fully appreciate the predicament, we should all await Stable Release of Gapcoin Core v0.16.3 - across all platforms (hopefully) ...

See: Software release life cycle - Release Candidate (RC)
- https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate

I personally need some more time to test and review everything.

"Bitcoin OG" 1JXFXUBGs2ZtEDAQMdZ3tkCKo38nT2XSEp | Bitcoin logo™ Enforcer? | Bitcoin is BTC | CSW is NOT Satoshi Nakamoto | I Mine BTC, LTC, ZEC, XMR and GAP | BTC on Tor addnodes Project | Media enquiries : Wu Ming | Enjoy The Money Machine | "You cannot compete with Open Source" and "Cryptography != Banana" | BSV and BCH are COUNTERFEIT.
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 03, 2021, 01:43:03 PM
 #2294

Excerpt;
Quote
== Generating ==
generate nblocks ( maxtries )
generatetoaddress nblocks address (maxtries)
getgenerate
getwork ( "data" )
setgenerate generate ( genproclimit ) ( sievesize ) ( sieveprimes ) ( shift )
I debated with myself whether to mention generatetoaddress in my response. Although I haven't checked, because I haven't interfered with any of that particular code, I have no reason to doubt its flawless functioning. The trouble is that in-wallet mining of BTC on mainnet was (correctly) considered futile by the Bitcoin devs as far back as 0.13, nearly five years ago - at which point the code for the internal miner was removed from Bitcoin.

One of the key implications of this is that the remaining generator code in the Bitcoin codebase is intended solely for use with testnet/regtest.

The practical consequences are that generatetoaddress isn't suitable for use as a general-purpose, run-until-stopped miner. The call takes three arguments: the target number of blocks to generate, the address to which they should be credited and, importantly, the maximum number of tries to attempt before returning - generatetoaddress nblocks "address" ( maxtries ) - and then it stops and you need to call it again. It's not that it can't be driven from a bash/Powershell script, it's just that this additional technical demand imposes a higher barrier to entry.

However, the Bitcoin code that implements the address-handling for the generatetoaddress function is obviously a candidate for copying and pasting. If it's perceived as highly-desirable to integrate this functionality into the in-wallet miner, one approach would be to store a mining address in the gapcoin.conf file and pick up the value from that.

Be advised though, having all the mined blocks going to one address compromises anonymity but if there's a compelling use case, I would be prepared to consider putting in the time and effort to get it to work.

Cheers

Graham
BitcoinFX
Legendary
*
Offline Offline

Activity: 2646
Merit: 1720


https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF


View Profile WWW
March 03, 2021, 02:32:13 PM
Last edit: March 03, 2021, 02:44:13 PM by BitcoinFX
 #2295

Excerpt;
Quote
== Generating ==
generate nblocks ( maxtries )
generatetoaddress nblocks address (maxtries)
getgenerate
getwork ( "data" )
setgenerate generate ( genproclimit ) ( sievesize ) ( sieveprimes ) ( shift )
I debated with myself whether to mention generatetoaddress in my response. Although I haven't checked, because I haven't interfered with any of that particular code, I have no reason to doubt its flawless functioning. The trouble is that in-wallet mining of BTC on mainnet was (correctly) considered futile by the Bitcoin devs as far back as 0.13, nearly five years ago - at which point the code for the internal miner was removed from Bitcoin.

One of the key implications of this is that the remaining generator code in the Bitcoin codebase is intended solely for use with testnet/regtest.

The practical consequences are that generatetoaddress isn't suitable for use as a general-purpose, run-until-stopped miner. The call takes three arguments: the target number of blocks to generate, the address to which they should be credited and, importantly, the maximum number of tries to attempt before returning - generatetoaddress nblocks "address" ( maxtries ) - and then it stops and you need to call it again. It's not that it can't be driven from a bash/Powershell script, it's just that this additional technical demand imposes a higher barrier to entry.

However, the Bitcoin code that implements the address-handling for the generatetoaddress function is obviously a candidate for copying and pasting. If it's perceived as highly-desirable to integrate this functionality into the in-wallet miner, one approach would be to store a mining address in the gapcoin.conf file and pick up the value from that.

Be advised though, having all the mined blocks going to one address compromises anonymity but if there's a compelling use case, I would be prepared to consider putting in the time and effort to get it to work.

Cheers

Graham


Here's an example of a miner that would appear to be mining blocks to a single address ... not me! ...  Cheesy

- https://chainz.cryptoid.info/gap/address.dws?GUNtDqH8QxesjU9p3TsE7LPkRjtGUykWrp.htm

As mentioned, it's not really a great idea in terms of anonymity or privacy, but I guess it adds some convenience to the mining process.

...

"We Got The Gun by Clint Mansell from Darren Aronofsky's Original Soundtrack"
- https://youtu.be/AFn-Wr3qDTY *Explicit Lyrics*

"Bitcoin OG" 1JXFXUBGs2ZtEDAQMdZ3tkCKo38nT2XSEp | Bitcoin logo™ Enforcer? | Bitcoin is BTC | CSW is NOT Satoshi Nakamoto | I Mine BTC, LTC, ZEC, XMR and GAP | BTC on Tor addnodes Project | Media enquiries : Wu Ming | Enjoy The Money Machine | "You cannot compete with Open Source" and "Cryptography != Banana" | BSV and BCH are COUNTERFEIT.
wizz13150
Member
**
Offline Offline

Activity: 67
Merit: 26

Tempus Narrabo


View Profile
March 03, 2021, 04:01:52 PM
 #2296


Whilst I fully appreciate the predicament, we should all await Stable Release of Gapcoin Core v0.16.3 - across all platforms (hopefully) ...
[...]
I personally need some more time to test and review everything.

True.
I'm on testnet since 07/11/2020, day of pre-release of Alpha available.
C'mon, "pre-release" and "Alpha", seem's crystal clear to me.
Absolutely no indication was given to switch to the mainnet. It's the opposite.
I'll wait.

I also see that a lot of work is done in the shadows. After 6 or 7 years, no need to rush this part there.
So I'll just add Good luck and Good work guys !

Wizz_^
gjhiggins
Legendary
*
Offline Offline

Activity: 2254
Merit: 1278



View Profile WWW
March 03, 2021, 09:17:24 PM
Merited by Welsh (20)
 #2297

I was not really aware that I had 'announced' anything as such, rather I posed some questions to the community with a possible upgrade schedule.

'My bad' and apologies for any confusion or panic caused.

However, when an alpha Release Candidate is available for download, people often take it as read that they can safely 'upgrade', which is clearly not the case.

I did not add the windows alpha Release Candidate to https://gapcoin.club

The new core repository is made available as a link, in the hopes of attracting additional developers to assist Graham ...
[ ...]

We have a Gapcoin testnet.

- https://bitcointalk.org/index.php?topic=822498.msg55546099#msg55546099

Please don't rush to 'upgrade' on mainnet, before any 'official' release announcements are made.

Graham is continuing to do sterling work in regards to development and I hope others will become more involved with helping as we progress.

Not a 'bad' as such and absolutely no need to apologise (you are doing a sterling job acting as the mainstay of this community project) - it's just that I'm trying to be acutely aware of the general group perception - whilst the chain consensus is fixed by proven code, the community consensus is highly sensitive to changes in sentiment.

If you’ll (all) bear with me, I will take you on a leisurely trip which I believe is necessary if you want to understand the full significance of the destination - which is: “Gapcoin 0.16.3 is milled from a Minkiz Foundry template, so that’s the version that can and should be released as the one endorsed by the community.” There’s some groundwork I need to lay in order for me to feel comfortable that people actually understand what that means ....

I'll freely confess to not viewing myself as a C++ developer - at least not according to my standards. I'm a cognitive psychologist by discipline and a cognitive scientist by profession, over my 30-year career in tech, I have acquired some familarity with the tools of computational modelling - in my time, I've coded in COBOL, Z80 assembler, BASIC, Pascal, LISP, POP11, Prolog, Smalltalk, Python and lately C++, not to mention acquiring familarity with the markup languages such as HTML, XSL, XSL, RDF, etc. More importantly, along the way, I've acquired some limited degree of skill in software engineering generally which gives me quite a good grounding for curating altcoin codebases in the (permanent) absence of the original developer.

The basic codebase of the current Gapcoin 0.16 client is derived from a piece of personal (and private) work that I've been pursuing over the last five years. Back in 2014, there was slew of trivial altcoin clones of Bitcoin, differing little from the cloneparent other than in the choice of hash algorithm and I created a piece of online “art” (Minkiz’s Foundry) which (I felt) made some wry commentary on the trend. It’s still up there, unchanged from 2014.

The (allegedly wry) commentary lies in the tongue-in-cheek ebullient description of the (total of 24) hashing algorithms, here’s a pageshot of the first half-dozen, the entirety are still available to view.






Perhaps understandably, the contents of the page linked to from the “Try/Buy” button confused some people, although it might look like a shitcoin generator, it’s non-functioning.




Minkiz Foundry is an extension of the idea behind my original investigation - can altcoin clones be successfully characterised by their differences from the Bitcoin cloneparent? This was (for me, at least) a natural outgrowth of the altcoin classification work I had done in DOACC (Description of A CryptoCurrency), a semantic web project¹

The DOACC ontology provides a means of describing the metadata of an altcoin.

Between 2014 and 2017 I spent quite some time collecting and collating the metadata of around 3500 altcoins of the time, here's an example (rendered in N3):
Code:
doacc:D002ce66d-0f79-4bcb-8725-ff14cea1dd85 a doacc:Cryptocurrency,
        doacc:Repository ;
    rdfs:label "Devcoin"^^xsd:string ;
    dc:title "Devcoin"@en ;
    doacc:block-reward "5000"^^xsd:string ;
    doacc:block-time 600 ;
    doacc:comment "established"^^xsd:string ;
    doacc:date-founded "2013-08-01"^^xsd:date ;
    doacc:expiration "listed"^^xsd:string ;
    doacc:image "devcoin_dvc.png"^^xsd:anyURI ;
    doacc:incept "2013-08"^^xsd:string ;
    doacc:pow doacc:D0441786b-85a1-45a6-a50d-1a9b80ec7b94 ;
    doacc:protection-scheme doacc:D451a49d8-c9e7-46e5-8b8d-bcbe16f75c24 ;
    doacc:protocol doacc:Db8ade99f-11f1-476b-ae77-03c005c1bb66 ;
    doacc:source "https://github.com/Unthinkingbit/charity/blob/master/bitcoinshare.html"^^xsd:anyURI  ;
    doacc:symbol "DVC"^^xsd:string ;
    doacc:total-coins "21000000000"^^xsd:string ;
    doacc:website "http://devcoin.org/"^^xsd:anyURI ;
    rdfs:comment "SHA-256 based crypto-currency with re-target every 1 day, 50K coins per block, and 21 billion total coins.
Merge-mined with BTC, 90% of generation goes to foundation, 10% to miners Dev Coin - Devcoin Abbreviation: DVC
Algorithm: SHA-256 Date Founded: 8/1/2013 Total Coins: No Limit Confirm Per Transaction: Re-Target Time: Block Time: 10 Minutes
Block Reward: 5,000 Coins Diff Adjustment 2,016 Blocks Website Thread Source up0 users have voted."^^xsd:string ;
    skos:prefLabel "Devcoin"@en .


The description is cross-referential - the PoW scheme for Devcoin is D0441786b-85a1-45a6-a50d-1a9b80ec7b94 which resolves to:
Code:
doacc:D0441786b-85a1-45a6-a50d-1a9b80ec7b94 a doacc:PoWscheme ;
    rdfs:label "SHA2-256"@en ;
    dc:description "NIST SHA2, 2001"@en ;
    rdfs:isDefinedBy <http://purl.org/net/bel-epa/doacc> ;
    skos:prefLabel "SHA2-256"@en .
(I use RDF for its sheer representational power, it's appropriate for this task).


And, with the vast majority of altcoins having a Github source to peruse programmatically, I was able to build tables showing the various features of altcoins - here it shows the cloneparent, its version, the (supposed to be unique to the coin²) “magic bytes” and the feature set:





However, behind the scenes, for my private amusement/edification and inaccessible to the public, the actual joke is that Minkiz Foundry does actually work, it successfully mills full-functioning altcoin clones i.e. includes the creation of the genesis block and the in-wallet miner is capable of generating mainnet blocks.

I've been tracking the Bitcoin cloneparent upgrades and Minkiz Foundry is now milling clones of Bitcoin 0.20. Over time, I've refined the set of choices of hash algorithm, replacing some outdated or less-interesting variants with implementations of more powerful or more interesting modern hash algos --- a handful of NIST first-round candidates that remain secure but never made it the NIST 2nd round and so never had an ASIC implementation (“In the final round of the competition, there were three complete ASIC implementations of the 256-bit versions of all five finalists”), MD6 (withdrawn by Ron Rivest from the NIST SHA-3 competition but later proven robust against differential cryptanalysis), Rainforest, City (Google’s own) and some algos approved by other-nation NIST equivalents such as the Chinese SM3 and the Russian GOST-Streebog ... (I hope you’ll forgive me for including the full pageshot, I just happened to have one on imgur):





By way of illustration, here's a screenshot of a recent milling of Boat, a couple of nodes mining on a local mainnet:



I’d like to stress the importance of how close many algo-variant altcoins are to the Bitcoin cloneparent. My approach is to replace all the user-facing coin-specific “Bitcoin” strings (and their case variations) with a Jinja2 template expression: {{coinname}}, {{coinlcname}}, etc. I do the same for all of the other coin-specific variations (e.g. {{mainnetport}}) - it's a process that takes a couple of hours. The end result is a Minkiz Foundry template that is amenable to template-engine replacement (courtesy of Python and the Jinja2 templating engine) of all the relevant variations with coin-specific values maintained in a Python dictionary of just a couple of hundred items (of which a good half are merely testnet/regtest values).

Where altcoins vary more substantially from the cloneparent than just in hash algo (e.g. Namecoin, Peercoin, Datacoin, any altcoin with masternodes), my approach is to create a branch variant and apply the same template approach to the variant. For example, the 0.16.3 version of Datacoin is milled from a Minkiz Foundry branch-variant template.


(It's quite a high-power approach. A few months ago one of the Datacoin folks asked me how difficult it would be to add PoS to Datacoin. In just a few hours I was able to blend the Peercoin branch variant with the Datacoin branch variant and produce a version of Peercoin augmented with Datacoin’s per-transaction data storage and fee structure.)

To be honest, maintaining the branch-variants isn’t all that taxing, thanks to the excellent software engineering tools now available. I use meld to assist me with maintaining the branch variants as well as identifying the necessary variations. Here’s an example of just how limited the difference is in block structure for a Primecoin-clone such as Datacoin that needs to extend the block structure in order to carry PoW-relevant data about the specific prime chain and its length at that point in the chain:




Gapcoin is a similar branch variant. It’s the same as Bitcoin except that it uses a prime gap search PoW algo instead of a hash algo - it’s quite similar to Primecoin in that the block structure is extended to carry key information about the primes in order to facilitate the PoW calculation and ultimate rendering as a hash:



So, finally, you have the semantics to ground your understanding of what I mean when I write “Gapcoin 0.16.3 is milled from a Minkiz Foundry template”. It's not a trivial statement, there’s a lot of solid work to underpin it.

As regards the reliability of the Gapcoin 0.16.3 client ... the version in my own Github repos has inherited a bit too much from the Minkiz Foundry template. It’s alright for me to muck about in private, trialling code that I believe enhances the appeal to users because I'm not intending to use it in anger. So it’s not really all that surprising that I’ll miss a trick now and again. The reason I made the comment about being caught off-guard was simply to communicate that this wasn’t a random bug but the result of a specific, identifiable - and addressable cause which is highly unlikely to be repeated.

Ideally, I’d prefer that all of the tests in the Gapcoin unit test suite passed. Unfortunately, quite a lot of the Bitcoin test suite is specific to Bitcoin and amongst the coindevs of my acquaintance, getting the tests to pass is a known PITA. Many’s the time I’ve eagerly examined the test suite of a altcoin newly-launched by a strong dev/team only to discover that the tests I was interested in knowing how to get working had simply been removed.

Let’s face it, the closer the Gapcoin codebase is to a contemporary Bitcoin cloneparent, the more confident we can be in its reliability and robustness. The qualifying term “contemporary” is rather important here - just check the Bitcoin CVE list from CVE-2015-3641 onwards - you will note that they all apply to the 0.9 client. (And in case you were wondering, the Gapcoin 0.16.3 client is the patched version and is not vulnerable to the recently-identified invdos attack.)

Usually, problems only originate when devs make changes to the code without overwhelmingly good reasons. I recently identified this commit to the Verge codebase as the likely cause of the recent long range hack in which more than six months worth of transactions and balances vanished from the Verge blockchain. This conjecture was confirmed by zawy12. (The “coindevs of my acquaintance” that I mentioned earlier are subscribers to the invite-only “CryptoDevs” Discord server of which I’m privileged to be an invited member - there are many highly-skilled and knowledgable subscribers, including zawy12 and some very well-known altcoin devs).

Please bear in mind here that I'm addressing what I perceive to be a community consensus, my perceptions may well not match the reality but unfortunately, there’s no way to find that out.

As regards the 0.16.3 client, I think that for the moment, the best course of action is for me to provide, in the Gapcoin-project repos, a “vanilla” Gapcoin 0.16.3 client, stripped of (nearly all) the extravagant additions of the client in my own Github repos. I write “nearly all” because I imagine the consensus would prefer to retain the in-wallet miner (removed from the Bitcoin codebase back in 0.13 and restored by me for Minkiz Foundry purposes) but not the GUI mining page (use setgenerate or the external, more readily configured, GapMiner), nor the chart of hash/difficulty on the overview page,  nor the GUI block explorer (use getblock), nor the list of prime gaps (use listprimerecords), nor the multisig GUI (use addmultisigaddress), nor the make/showkeypair RPC/API calls, nor the other RPC/API calls that I haven’t mentioned such as dumptriples, renderblockhash and nicely - and the embellishment of "About Gapcoin".

Please don’t mistake this for a fit of pique, it’s just being realistic about the (rather remote) chance of BitcoinFX managing to persuade someone else to work on the codebase. No-one will want to maintain all the frippery that I have added but a barebones clone with essential coin-specific changes would be a different matter.

And that position is quite readily attainable by milling a basic Minkiz Foundry 0,16.3 variant-branch template. It doesn’t mean that I will delete my Gapcoin repos, far from it, it just increases the likelihood of other people contributing to the mainstream Gaocoin codebase

I'm likely to make available a couple of versions of the enhanced Gapcoin client, a “GT” version with the GUI additions and a "de luxe" version with all the features I addded. As people begin to develop a more extensive model of the Gacoin 0.16.3 codebase, they may well come to appreciate the reliability of the basic codebase and understand that the additions are non-intrusive to the basic functioning of the client.

And, now that I've exposed the back-end workings of the Minkiz Foundry, the existence of a Gapcoin 0.20 client should be less of a surprise ... to give you a hint, here's a screenshot of the Ferrari 0.20 mining page that you might find a little familar:



It may be that not all the additions will get migrated to the 0.20+ codebase (I'll be working on the Minkiz Foundry 0.21 template sometime in the not-too-distant future). In particular 0.20 has seen an extensive rewrite of the network processing code and I ran into some as-yet-unresolved issues when porting over the DANDELION code and I've been informed by one of my coindev colleagues that with 0.20 the wallet code has been strongly modularised (i.e. more self-contained) and correspondingly is a lot more challenging to integrate with the miner. However, on balance, it’s far more important to retain upgrade compatibility with the strongly-developed upstream code (i.e. Bitcoin) and gain the benefit of improved reliablility, transaction security (anticipating stuff like Schnorr signature aggregation, etc) and all the other benefits accruing from the strength of the Bitcoin developers.

Ultimately, while I will freely confess that I'm not a C++ developer according to my standards, it doesn't mean that I harbour any deep misconceptions about the strength and depth of my technical skillset. From the above you may have formed (the intended) impression that I am highly accomplished and operate at a very high standard. At this level, one doesn’t find people needing to cope with feelings of inferiority by over-extolling their own skills, rather the reverse. People who work at really high-levels of accomplishment are readily characterised by what might appear to the uninitiated as excessive modesty and over-respect for other professionals. It's a bit of a tell-tale as it’s a useful kind of idiot filter; in general, anyone who doesn’t understand the origin of the modesty and reciprocate the respect is, in effect, signalling their relative inferiority on the technical scale of things.

If you’ve followed this leisurely journey all the way to here, then I salute you --- and I thank you, I have been able to communicate a lot of information about the Gapcoin codebase in a way that would be impossible without your understanding of the background and how the Gapcoin 0.16.3 client came to be.

Cheers

Graham


¹ pursuing cognitive science as a profession quickly gets one into “classical” AI, an area I worked in during the late 80s/early 90s in R&D as an HPLabs engineer (back when HP Labs was one of the FAANGs of the time) hence my interest in the semantic web, which is where many classical AI folks are now to be found (notably, e.g. Pat Hayes).


² A change to the message-identifying “magic bytes” from their Bitcoin-specific values is something of a signifier of an altcoin cloned by a capable and experienced developer. Many script-kiddie altcoin devs were ignorant of the implications of failing to follow this strong recommendation.

UsernameNumber7
Member
**
Offline Offline

Activity: 256
Merit: 60


View Profile
March 04, 2021, 04:55:04 AM
 #2298

Is it possible to remove the HD Wallet from the 16.3 Wallet?  Is it that desirable to have?  


I had to use a blockchain backup to restore the 16.3 wallet after trying to start Version 9 Gapcoin to transfer coins into new wallet.

Didn't wait for it 1 day to re-index the blockchain which is what it wanted to do after mining with 16.3 for 1 day.  Going back to Version 9 even with a Version 9 wallet makes it want to Re-Index the entire blockchain.  


Too much trouble probably.  


Keep a Pre-16.3 Blockchain Backup close by to restore Version 9 wallet.  I have not got around to it, but I am sure it will work, but it does not work with saving the blockchain after 16.3 wallet has mined to go backwards and restart Version 9 wallet.  It will but Re-Indexing is not ok for time.  

With a Pre-16.3 Blockchain backup Version 9 Wallets should just need to Re-Scan which takes only a few hours instead of over a day and it restarts from the start if you shut it down while Re-Indexing.

Hard to explain, but I am not looking back.  

A couple years ago while using a Israeli VPN I had Mossad steal a transaction from me for around 500,000 GAP.  Not sure if they got the private keys or if they are just Burned Coins.  As I was using Tor over the VPN, but it's possible they compromised Tor as well to steal the private keys.  The transaction was sent using Israeli VPN server over Tor.  Hopefully it's just Burned Coins anyway.  


https://www.TRISQUEL.INFO #1 Free Software Linux Operating  System

Trisquel OS "Just Do It"        "Sic Semper Tyranis"
Kameleonic
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
March 04, 2021, 02:40:39 PM
 #2299

Hey guys, im having problems setting up the node to start mining GAP, There are no connections in my wallet and also I dont understand how to add nodes, should I create the gapcoin.conf file myself and format it similar to other qt based miners? Any help would be great obviously theres 6 years of blockchain to sync aswell, surely someone has a link to a recent backup that saves me 24hours of tea bagging my PC unnecessarily.

Thanks in advance.

Kind Regards
Kameleonic
cryptomaxsun
Legendary
*
Offline Offline

Activity: 2744
Merit: 1387


Ukrainians will resist


View Profile WWW
March 04, 2021, 03:01:11 PM
Merited by xandry (3)
 #2300

Hey guys, im having problems setting up the node to start mining GAP, There are no connections in my wallet and also I dont understand how to add nodes, should I create the gapcoin.conf file myself and format it similar to other qt based miners? Any help would be great obviously theres 6 years of blockchain to sync aswell, surely someone has a link to a recent backup that saves me 24hours of tea bagging my PC unnecessarily.

Thanks in advance.

Kind Regards
Kameleonic
Node List for /Satoshi:0.9.2/
https://chainz.cryptoid.info/gap/#!network

Code:
addnode=138.197.159.202
addnode=172.104.88.43
addnode=178.221.183.154
addnode=199.195.250.77
addnode=199.247.26.15
addnode=46.101.235.143
addnode=51.79.69.241
addnode=62.105.2.178
addnode=93.75.240.21
addnode=95.179.139.125
addnode=95.179.179.21
addnode=95.179.182.168

Download blockchain to fast synchronization - https://gapcoin.network/downloads/Gapcoin_blockchain.zip

create the gapcoin.conf file in the folder where the blockchain is stored Gapcoin.
 Windows - %APPDATA%\Gapcoin\ - C:\Users\username\AppData\Roaming\Gapcoin\gapcoin.conf
 Linux - $HOME/.gapcoin/ - /home/username/.gapcoin/gapcoin.conf

❘|❘ Cлaвa Укpaинe! ❘|❘ Glory to Ukraine! ❘|❘
❘|❘ КaPФaгeн дoлжeн быть paзpyшeн ❘|❘
Pages: « 1 ... 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 [115] 116 117 118 119 120 121 122 123 124 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!