Verionum
Jr. Member
Offline
Activity: 89
Merit: 3
|
|
August 24, 2017, 10:43:03 PM Last edit: August 25, 2017, 06:50:04 AM by Verionum |
|
The original version of primecoin-hp14 has a built-in donation code. I think it can be easily removed from the source code. But it is not very important. Getting the speed up to HP-14 will be a significant achievement. I am more interested in functional improvements. Such improvements can raise up the popularity of DTC. I am looking into an alternative possibility, trying to develop a working understanding of the precise outline of Datacoin's footprint on the Primecoin codebase and how well (or otherwise) that might transfer to a more recent codebase. I've not made much progress, it's a labour-intensive process - as you observed. I think it is meaningless. The latest version of primecoin is very old also. It seems Primecoin-HP14 is already latest version. There is no any other recent version of primecoin . Which recent codebase do you mean? If you mean the recent bitcoin code there will be another problems. I can try to define the difference between datacoin (primecoin) and the original bitcoin code. I can analyze this difference then apply it to the latest bitcoin code. But latest bitcoin code is very changed. For example it has SegWit support. I did not look into SegWit. I don't sure the above mentioned difference can be successfully applied to bitcoin code without taking SegWit into account. But I can try to do it. Can you advice me something? The Datacoin adaptation is in its early stages. The presentation uses calls on the JSON-RPC API of the node to get its block and tx data. Address data has to be collated off-chain because basically, a wallet is a transaction explorer, scoped to a set of addresses. The index maintained by the wallet is transaction -> address but to browse addresses, the index needs to be address <- transaction, hence the RDF+SPARQL with the added advantage that the RDF graph is replicable, i.e. publishable and amenable to ad hoc interrogation by means of SPARQL query. Do you need transaction metadata by address? Do you mean payment addresses or transaction addresses (hash)?
|
|
|
|
Kumic
|
|
August 25, 2017, 05:51:02 AM |
|
I would like to join and mine this coin or should I run a node. Can somebody help me here? Thank you.
Try these nodes: 80.74.157.31 144.76.64.49 104.236.250.232 82.36.172.103 Thank you for helping me. I have 3 active connections. New coin named DATAcoin coming soon.
|
|
|
|
id10tothe9
|
|
August 25, 2017, 07:18:48 AM |
|
uh the wallet teaser looks beautiful, seems like an interesting project. are you guys going to do something serious with this coin, I understand it's just a fork for testing?
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 25, 2017, 10:01:19 AM |
|
The original version of primecoin-hp14 has a built-in donation code. I think it can be easily removed from the source code. But it is not very important.
Yes, it can be easily removed or, as the author notes, disabled. I also note that the community has been seeking technical contributors for some time and I'm sort of sensitive to the apparent message that stripping out/disabling the donation code would send. Getting the speed up to HP-14 will be a significant achievement. I am more interested in functional improvements. Such improvements can raise up the popularity of DTC. Sure, each to his own and all that. My own attempts to create an non-donation HP-14 version reflect my understanding that Datacoin differs from most other PoW-based alts in that the economic benefit of the work done isn't constrained to merely supporting the altcoin's internal token value system but also contributes to overall mathematical endeavour and it's that aspect that is enhanced by speeding up the calculation of primes. I am looking into an alternative possibility, trying to develop a working understanding of the precise outline of Datacoin's footprint on the Primecoin codebase and how well (or otherwise) that might transfer to a more recent codebase. I've not made much progress, it's a labour-intensive process - as you observed. I think it is meaningless. The latest version of primecoin is very old also. It seems Primecoin-HP14 is already latest version. There is no any other recent version of primecoin . Which recent codebase do you mean? If you mean the recent bitcoin code there will be another problems. I can't say for sure right now, it all depends on how big a footprint, i.e. how much of the original code was changed. I'm guessing that an upgrade to Core 0.10 could be reasonably straightforward, depends on how much work is required to bring the getwork side of things up to date. The change to using block headers is (AIUI) currently presenting an upgrade barrier to most PoS alts. I've been advised that PIVX is Core 0.12 and uses PoS but I've also noted that where overlay node alts are concerned, the “0.12“ is actually 0.10 under the hood (the version numbers of the “release notes” files on docs are often instructive). The Datacoin adaptation is in its early stages. The presentation uses calls on the JSON-RPC API of the node to get its block and tx data. Address data has to be collated off-chain because basically, a wallet is a transaction explorer, scoped to a set of addresses. The index maintained by the wallet is transaction -> address but to browse addresses, the index needs to be address <- transaction, hence the RDF+SPARQL with the added advantage that the RDF graph is replicable, i.e. publishable and amenable to ad hoc interrogation by means of SPARQL query. Do you need transaction metadata by address? Do you mean payment addresses or transaction addresses (hash)? The former, which is not available directly from the JSON API. The latter is expressed directly in the results from getblock and is mapped to RDF. If this is the verbatim straight JSON: ~/bin/datacoin getblock 9c4a0c53dc5c2da031cc9515daa29c91f151f033b9d78eca648b6acbc46157b0 { "hash" : "9c4a0c53dc5c2da031cc9515daa29c91f151f033b9d78eca648b6acbc46157b0", "confirmations" : 1, "size" : 198, "height" : 1979931, "version" : 2, "headerhash" : "c05f00c01f9c759833fa5b104b08d2270bf6e0e7e0d006c456dba27f002e5edc", "merkleroot" : "3f95b66ed63a722f2bc7ba558953157c0ca97e097b1ec68677703f45f51fdf98", "tx" : [ "3f95b66ed63a722f2bc7ba558953157c0ca97e097b1ec68677703f45f51fdf98" ], "time" : 1503653771, "nonce" : 465138, "bits" : "07c80f68", "difficulty" : 7.78148508, "transition" : 7.96567649, "primechain" : "2CC07.fcb7d4", "primeorigin" : "5049200510910873383815124963229437742780997306869231794732113951576948673432067 51904218000", "previousblockhash" : "eeab89f0199fe1dc74cf6821afeb338aaa3091875203106b94f017a2e034c67a" } It is readily expressible in JSON-LD, of which the below is an arbitrary and roughly sketched-out example because I skipped this intermediate stage of mapping: { "@context": "https://purl.org/net/bel-epa/ccy#", "@id": "C9c4a0c53dc5c2da031cc9515daa29c91f151f033b9d78eca648b6acbc46157b0", "type": "https://purl.org/net/bel-epa/ccy#Block", "confirmations" : 1, "size" : 198, "height" : 1979931, "version" : 2, "previousblockhash" : "https://purl.org/net/bel-epa/ccy#Ceeab89f0199fe1dc74cf6821afeb338aaa3091875203106b94f017a2e034c67a" }
The above will fail a validator, it's merely an attempt to demonstrate that it's a mapping (for a more thorough understanding, see the JsoN-LD docs). SPARQL queries return transaction metadata by address (or date, or block, or with/without data, or ...). Cheers Graham
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 25, 2017, 10:07:30 AM Last edit: August 25, 2017, 11:03:46 AM by gjhiggins |
|
uh the wallet teaser looks beautiful, seems like an interesting project. are you guys going to do something serious with this coin, I understand it's just a fork for testing?
Thanks for the positive response. It's not a wallet, it's a web app talking to the wallet. The visual aspects are courtesy of the Semantic-UI CSS framework which I omitted to credit. You can toggle between viewing metadata for mainnet and testnet by clicking on the coinlogo+name in the navbar (an easter egg). Cheers Graham (edit: added URL, clarified)
|
|
|
|
Chicago
|
|
August 25, 2017, 12:09:32 PM |
|
Why getinfo doesn't print difficulty?
{ "version" : "v0.1.2.0dtc-hp11-g791125b9-beta", "protocolversion" : 70001, "walletversion" : 60000, "balance" : "blocks" : 1978127, "moneysupply" : 26187045.02783475, "timeoffset" : 0, "connections" : 2, "proxy" : "", "testnet" : false, "keypoololdest" : 1503367205, "keypoolsize" : 101, "paytxfee" : 0.00000000, "errors" : "" }
Hello Mightinside, The difficulty isn't included in the original code either. Easiest way to see the current difficulty would be to: prime ~ # grep SetBestChain /var/lib/datacoin/debug.log | tail -n 1 2017-08-25 12:06:47 SetBestChain: new best=e55e565f854fd3aba8aa3c1f9ae80dd926f1306fd6cb14e51f2d98e3b64aeb7b height=1980097 difficulty=7.7821499 log2Work=15.045162 log2ChainWork=44.258783 tx=2265955 date=2017-08-25 12:06:45 progress=0.999999
Simply replace /var/lib/datacoin/debug.log with the location where your datadir/debug.log exist. Best Regards, -Chicago
|
|
|
|
Mightinside
Newbie
Offline
Activity: 7
Merit: 0
|
|
August 25, 2017, 12:23:05 PM |
|
thanks, Chicago
btw, confirmations stop performing for more that 2 days, any thoughts?
|
|
|
|
Chicago
|
|
August 25, 2017, 12:29:43 PM |
|
The current DTC code is very old.
Indeed it is. But importantly, it is a full clone of Primecoin and retains the prior commit history. I can try to upgrade the code. Is it meaningful?
Yes, it is. The Primecoin codebase has been improved since the Datacoin fork. It is now at hp-14 (improvements to the speed). One route to upgrading Datacoin is by integrating those subsequent improvements. Hello Gentlemen, The latest upstream tagged release is from 2013 at v0.8.6 for the Primecoin repository. That's obviously not the state of the art. The last commit upstream was on July 21st, 2014. What is the lineage of the primecoin-hp branch? Has there not been an official Sunny King update to the Primecoin sources since Bitcoin v0.8.6? If not, then why? Aren't there big issues with non DER encoded signatures which cause forks across architectures? Current Datacoin is minting version 2 blocks. BIP66 which enforces strict DER signatures isn't inherited in our code from upstream since activation/enforcement came long after Bitcoin v0.8.6. It almost feels like the right thing to do is make a Datacoin network upgrade on the Bitcoin v0.10 sources which introduce BIP66 and then BIP65. By the time we get there we will know what commits "make Primecoin" so that we can "make Datacoin" again on top of more recent Bitcoin. It is more work but I have to wonder why there haven't been updates to Primecoin's repository in so long. Best Regards, -Chicago
|
|
|
|
Chicago
|
|
August 25, 2017, 12:34:01 PM |
|
btw, confirmations stop performing for more that 2 days, any thoughts?
Hello Mightinside, Here's why! The coinbase maturity is 3000 blocks. The target spacing is one minute. Expect to wait 2.083 days for a mature coinbase reward. Python 3.4.6 (default, May 20 2017, 01:58:16) [GCC 5.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 3000 / 1440 2.0833333333333335 >>>
This feature enshrines well-secured data into the blockchain which resists reorganization quite heavily. Best Regards, -Chicago
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 25, 2017, 12:43:28 PM |
|
I found interesting attempt to develop new datacoin2107 "in shadow".
Looks more like someone at U of Georgia is finding their way around git. Why getinfo doesn't print difficulty?
Dunno, it's in the code. Added to issues list: https://github.com/gjhiggins/datacoin/issuesCheers Graham
|
|
|
|
Chicago
|
|
August 25, 2017, 01:08:43 PM |
|
Hello, I lied. Here is the easiest method to find difficulty, using the RPC. prime ~ # datacoind getdifficulty 7.78255534
Best Regards, -Chicago
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 25, 2017, 01:24:05 PM |
|
The last commit upstream was on July 21st, 2014. What is the lineage of the primecoin-hp branch? Has there not been an official Sunny King update to the Primecoin sources since Bitcoin v0.8.6? If not, then why? Aren't there big issues with non DER encoded signatures which cause forks across architectures? Maybe Sunny has relaxed his grip, maybe he's suffering from acute NIH. Someone did contribute a strict-DER fix: https://github.com/coinkeeper/2015-06-22_18-45_primecoinPerhaps it was just inadequately advertised. It does seem odd that it wasn't integrated into the “main” development effort, perhaps it fell short of Sunny King's standards. It almost feels like the right thing to do is make a Datacoin network upgrade on the Bitcoin v0.10 sources which introduce BIP66 and then BIP65. By the time we get there we will know what commits "make Primecoin" so that we can "make Datacoin" again on top of more recent Bitcoin.
It is more work but I have to wonder why there haven't been updates to Primecoin's repository in so long.
ISTM that there were some quite important changes, especially between the 0.9 and 0.10 versions, which basically render the latter as the minimum acceptable version according to contemporary perceptions of robustness and vulnerability. AIUI, there was general developer relief at getting 0.10 safely out of the door as it addressed various previously-unmentionable issues, some of which might not unreasonably be perceived as vulnerabilities to exploitation. Cheers Graham
|
|
|
|
Chicago
|
|
August 25, 2017, 01:54:02 PM |
|
ISTM that there were some quite important changes, especially between the 0.9 and 0.10 versions, which basically render the latter as the minimum acceptable version according to contemporary perceptions of robustness and vulnerability. AIUI, there was general developer relief at getting 0.10 safely out of the door as it addressed various previously-unmentionable issues, some of which might not unreasonably be perceived as vulnerabilities to exploitation.
Hi Graham, The v0.9 branch the way I've found it to be was a forklift move to the Autotools based build system. Then in v0.10 they started refactoring things. Pieces of code you can find in v0.8 branches of altcoins live in the same files in v0.9 Bitcoin --- but not anymore in v0.10, when they introduced chainparams style declaration of the coin specification. Best Regards, -Chicago
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 25, 2017, 08:46:50 PM |
|
Pieces of code you can find in v0.8 branches of altcoins live in the same files in v0.9 Bitcoin --- but not anymore in v0.10, when they introduced chainparams style declaration of the coin specification.
Ah, thanks for that clarification, I've not had the time to pin down the crossover details precisely. Thinking back, the coin I was upgrading was a straight clone, just param changes, so when they introduced 0.9, I just re-rebranded Bitcoin and migrated the coin's params to chainparams. Co-incidentally, the refactoring has given me an opportunity to lend a bit more depth to an existing piece of work ... More than one person has failed to detect the tongue-in-cheek nature of Minki’s Foundry: https://minkiz.co/foundry. Originally the advertised “latest Bitcoin Core release” was 0.9 because that's when I published the work. Riffing off've the re-rebranding and the distillation of the parameter differences into a single location, I created for myself a “template branch” of Bitcoin Core with all the re-rebranding and parameter distillation abstracted out and replaced by Jinja2 template statements. I had been playing around with the notion of distilling a coin's profile (hence the DOACC metadata collection http://github.com/DOACC/individuals) and for a while I toyed with the idea of trawling Github-hosted chainparams.cpp files and extracting the specific technical metadata for adding to DOACC. In the end, I brought DOACC to a close, it had served its purpose, and I decided to go in the opposite direction - use the metadata + templates to implement the Foundry offers. Now that the pow functionality has been handily abstracted out to pow.[cpp|h] it's just too tempting to resist. I'm too involved atm but I have a compiled version of FerrariBoat to return to at some point in the future. (The naming convention is homage to a classic Snickers ad: https://www.youtube.com/watch?v=anm2SWU_BHo) This is the YAML description of Chaincoin from a while ago, with Bitcoin values as end-of-line comments: CHC: checkpointestimatedtransactions: 572007 # 60000.0 checkpointtimestamp: 1434866355 # 1397080064 checkpointtotaltransactions: 960 # 36544669 checkpoints: [ [0, "0x00000f639db5734b2b861ef8dbccc33aebd7de44d13de000a12d093bcc866c64"], [6143, "0x0000000026fb51f5bc9943ed69d9ff7697ecf7fed419d88b417655f93a487ce1"], [12797, "0x000000002c29644e179baa188fa6b9b9454721f1f21f2b9f31eebe9acc1a31db"], [30092, "0x0000000098a23e1c503f71a6d61c333c5abaabb4c5fa1b474012e004db4bfbbe"], [80998, "0x000000010ebcfe9a00a99f2b61104f4a141555a707f1c007aba8a978f6030cfb"], [144759, "0x000000047e7b7bfd63b4f019a0a24c8d65b10afa6eb80721e10fa7c49ce6fb6e"], [189046, "0x00000000bd507c435b46ee8a13b25b85ec38fdb0eb5b00faeaa0611cd6a483d3"], [277316, "0x00000016a20503fe496e79d34fb85c33f633059315c046ffa1b4826d08a1e856"], [483849, "0x000001eb7f8124282ab62296e63d3145ff6c84cf18afae4d4b8e02cd3182b6a8"] ] # [[' 0', "0x0"]] clientname: "Satoshi" # "Satoshi" coinbasematurity: 100 # 100 coinlcname: "chaincoin" # "bitcoin" coinbsname: "chaincoin" # "bitcoin" coinname: "Chaincoin" # "Bitcoin" coindisplayname: ""Chaincoin" " # "Bitcoin" coinucname: "CHAINCOIN" # "BITCOIN" coinsymbol: "CHC" # "BTC" coinunit: "Chaincoin" # "Bitcoin" coinlcsymbol: "chc" # "btc" cointype: "0x80000005" # "0x80000005" proofofworklimit: "CBigNum(~uint256(0) >> 20)" # CBigNum(~uint256(0) >> 20) psztimestamp: "18-01-14 - Anti-fracking campaigners chain themselves to petrol pumps" # "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" defaultminrelaytxfee: 1000 # 1000 genesisblockhash: "0x00000f639db5734b2b861ef8dbccc33aebd7de44d13de000a12d093bcc866c64" # "0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f" genesisoutputscript: "04becedf6ebadd4596964d890f677f8d2e74fdcc313c6416434384a66d6d8758d1c92de272dc671 3e4a81d98841dfdfdc95e204ba915447d2fe9313435c78af3e8" # "" hashmerkleroot: "0xfa6ef9872494fa9662cf0fecf8c0135a6932e76d7a8764e1155207f3205c7c88" # "0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b" npowhumantargetspacing: "90 seconds" # "10 minutes" npowhumantargettimespan: "90 seconds" # "2 weeks" maxmoney: 30000000 # 21000000 mintxfee: 10000 # 10000 msgstrts: ["0xa3", "0xd2", "0x7a", "0x03"] # ["0xf9", "0xbe", "0xb4", "0xd9"] nbits: "0x1e0fffff" # "0x1d00ffff" nnonce: 2099366979 # 2083236893 nsubsidy: 16 # 50 npowtargetspacing: 90 # "10 * 60" npowtargettimespan: 90 # "14 * 24 * 60 * 60" ntime: 1390078220 # 1231006505 nvalue: 16 # 50 nversion: 1 # 1 port: 11994 # 8333 rpcport: 11995 # 8332 prefixnum: 28 # 0 scriptaddress: 4 # 5 scriptpubkeyhex: "0x" # "0x" secretkey: 156 # 128 subsidyhalvinginterval: 700800 # 210000 vseeds: [ ["seed1.chaincoin.org", "seed1.chaincoin.org"], ["seed2.chaincoin.org", "seed2.chaincoin.org"], ["seed3.chaincoin.org", "seed3.chaincoin.org"], ["seed4.chaincoin.org", "seed4.chaincoin.org"] ] # [] xpub: "(0x02)(0xFE)(0x52)(0xF8)" # "(0x04)(0x88)(0xB2)(0x1E)" xprv: "(0x02)(0xFE)(0x52)(0xCC)" # "(0x04)(0x88)(0xAD)(0xE4)" regtestcheckpointestimatedtransactions: 0 # 0 regtestcheckpoints: [] # [[' 0', "0x0"]] regtestcheckpointtimestamp: 0 # 0 regtestcheckpointtotaltransactions: 0 # 0 regtestnpowhumantargetspacing: "90 seconds" # "10 minutes" regtestnpowhumantargettimespan: "90 seconds" # "two weeks" regtestmsgstrts: ["0xfc", "0x1f", "0xc3", "0x56"] # ["0xfa", "0xbf", "0xb5", "0xda"] regtestproofofworklimit: "CBigNum(~uint256(0) >> 1)" regtestngenesisblockhash: "0x" # "0x0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206" regtestmerkelroothash: "0x" # "0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b" regtestnbits: "0x207fffff" # "0x207fffff" regtestnnonce: 3 # 2 regtestntime: 1296688602 # 1296688602 regtestnvalue: 16 # 50 regtestnversion: 1 # 1 regtestpubkeyaddress: 80 # 111 regtestscriptaddress: 44 # 196 regtestsecretkey: 208 # 239 regtestsubsidyhalvinginterval: 150 # 150 regtestnpowtargetspacing: 90 # "10 * 60" regtestnpowtargettimespan: 90 # "14 * 24 * 60 * 60" regtestport: 18444 # 18444 regtestrpcport: 18445 # 18332 regtestpub: "(0x04)(0x35)(0x87)(0xCF)" # "(0x04)(0x35)(0x87)(0xCF)" regtestprv: "(0x04)(0x35)(0x83)(0x94)" # "(0x04)(0x35)(0x83)(0x94)" testnetcheckpointestimatedtransactions: 960 # 300 testnetcheckpoints: [ [0, "0x0000082f5939c2154dbcba35f784530d12e9d72472fcfaf29674ea312cdf4c83"] ] # [[' 0', "0x0"]] testnetcheckpointtimestamp: 1388868139 # 1337966069 testnetcheckpointtotaltransactions: 0 # 1488 testnetgenesisblockhash: "0x0000082f5939c2154dbcba35f784530d12e9d72472fcfaf29674ea312cdf4c83" # "0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943" testnetmerkleroothash: "0x" # "0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b" testnetnpowhumantargetspacing: "90 seconds" # "10 minutes" testnetnpowhumantargettimespan: "90 seconds" # "two weeks" testnetmsgstrts: ["0xfb", "0xc2", "0x11", "0x02"] # ["0x0b", "0x11", "0x09", "0x07"] testnetnbits: "0x1e0fffff" # "0x207fffff" testnetnnonce: 423087994 # 1211565 testnetnpowtargetspacing: 90 # "10 * 60" testnetnpowtargettimespan: 90 # "14 * 24 * 60 * 60" testnetntime: 1388868139 # 1374901773 testnetnvalue: 16 # 50 testnetnversion: 1 # 1 testnetport: 21994 # 18333 testnetrpcport: 21995 # 18332 testnetpubkeyaddress: 80 # 111 testnetscriptaddress: 44 # 196 testnetsecretkey: 216 # 239 testnetsubsidyhalvinginterval: 150 # 210000 testnetvseeds: [] # [] testnetpub: "(0x3a)(0x80)(0x61)(0xa0)" # "(0x04)(0x35)(0x87)(0xCF)" testnetprv: "(0x3a)(0x80)(0x58)(0x37)" # "(0x04)(0x35)(0x83)(0x94)" testnetcointype: "0x80000001"
That pretty much does the main job. Not sure whether I can get enough abstraction to do the hash algo swapping by template, perhaps just a dynamically-computed patch for now. I s'pose I could ultimately publish FerrariBoat on the Datacoin blockchain in the form of a patch against a clone of a given Bitcoin Core version. Cheers Graham
|
|
|
|
Chicago
|
|
August 26, 2017, 03:04:29 AM |
|
Co-incidentally, the refactoring has given me an opportunity to lend a bit more depth to an existing piece of work ...
Hi Graham, This is brilliant. Last time I remember seeing Jinja2 used to get down and dirty is with Ansible. With this template; one could basically write a series of tasks and a playbook to essentially eliminate a whole lot of non-valued added work as it pertains to maintaining coin code. I will be looking to abstract a vanilla Litecoin v0.10.2.2 repository with the template methodology. That pretty much does the main job. Not sure whether I can get enough abstraction to do the hash algo swapping by template, perhaps just a dynamically-computed patch for now.
There is just a little bit more to do for changing the proof-of-work algorithm because all of the makefile.foo files in the 0.8 branch derivatives would need to have lines stricken and replaced. However, passing the tests -- which also involve updating the data used in the tests is going to be much easier when using a template with Ansible tasks. For example, updating the BitcoinMiner tests which have some precomputed solutions to a run of blocks -- or the Alert system tests which need to have some pre-signed messages with the new alert key, or the address tests where changing the Base58 prefix needs to happen or else they fail on new *foo*coin. So much more can be done than diff and patch or sed when you abstract the vanilla repository into a Jinja2 template. Your idea very much aligns with code re-usability and will promote sustainability of multiple coin networks. Best Regards, -Chicago
|
|
|
|
extro24
|
|
August 28, 2017, 10:15:43 AM |
|
The current DTC code is very old.
I can try to upgrade the code. Is it meaningful?
May be I will try to support it. I need a list of necessary improvements.
But I am a newbie in cryptocurrencies. I need the time for deep exploration of the original code and proposed improvements (if there will be any). It can take a month or more. Please write here if you are interested in.
Please write the list of necessary improvements.
Is it possible to integrate some new cryptocurrency technologies into DTC? If source code of such technologies is open I can try to integrate it.
How do you think?
1. Windows wallet needs to be updated. 2. Are you familiar with the anonymity features of Dash, Monero and Zcash? Maybe these could be added to Datacoin?
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 28, 2017, 08:50:37 PM |
|
1. Windows wallet needs to be updated. 2. Are you familiar with the anonymity features of Dash, Monero and Zcash? Maybe these could be added to Datacoin?
1. Noted. 2. Good questions. As Chicago has pointed out, there is a twisty-turny path to upgrading Datacoin to a clone of 0.10 Core. Dash is a clone of 0.10, as are its klonekinder. Monero uses the Cryptonote protocol and would be an unsuitable target. I've not investigated Zcash in any detail, so I don't have much sense of the degree of complexity of the migration. So right now, any “anonymity” feature is restricted to coin-mixing-via-overlay-network, a la Dash, i.e. not actually anonymous. On other matters, the entire(*) Datacoin blockchain has now been mapped to RDF, so addresses now resolve. It's a single-threaded server, straight Python (waitress) and I'm also not at all sure that I've configured Fuseki with sufficiently generous resources and because I'm still working on it, nothing is being cached, so response alacrity is “best effort” atm. (*) I accidentally-on-purpose omitted to copy the contents of the tx data field over to the RDF graph as the stored data isn't strictly metadata. Instead, in the next workspace over, as I write this, a small Python script is working its way methodically through the blockchain, recording the hash of each block that has one or more data txs, the hashes of those txs and the size of the stored data for the tx. Sample output, copynpasta'd: 790000 <- height achieved thus far ["2be1fffdb16c1163ece07029862f58fcc90f55e91dba42bd1f17a8f5a7187366", "1ec6a6370f603be614cc29338aeb2a9abaf55bb9a41012fb80e38bffd3c4b9de", 136], ["2be1fffdb16c1163ece07029862f58fcc90f55e91dba42bd1f17a8f5a7187366", "3b500c4bf2841c80bd3ff3ebe7090865e521bbc55ab753d0ba1cf16466595a5f", 140], ["2be1fffdb16c1163ece07029862f58fcc90f55e91dba42bd1f17a8f5a7187366", "1a3966eb8ac879c5de7d19675f46b7ffbe1074e57ab0b6c35c3287991b3b438b", 136], ["9da914b8e0236dda7e87c55e3079a0825c3be173119384ac636d732f9d77d536", "4ca286534961fc8ff10dd7e4ef3d42ccba9a9c3efac2b5aa23476f09cc6b6b2e", 136],you can try them out: http:// tessier.bel-epa.com port 5059 /main/tx/1ec6a6370f603be614cc29338aeb2a9abaf55bb9a41012fb80e38bffd3c4b9de I'll then add those facts to a separate RDF graph (to keep the blockchain mapping untainted) and re-do the exercise, this time using a routine that attempts to determine the MIME type of the stored data, which when confirmed, can be added to the graph. (If the way that ACME presents the metadata makes little sense to you, check out the accordion drop-down “Unprocessed JSON response”, that's what we have to work with - if anyone has suggestions for making a clearer presentation, please feel free to pitch in.) And before anyone jumps in to point out the obvious, a Python web app that marshals and presents data retrieved over the wire can be rewritten using a Javascript framework, browserified and embedded in the client, courtesy of Qt5's webengine implementation of v8. Windows binaries would have to be compiled natively because (aiui) there is no MXE cross-compiler implementation of qtwebengine because of, well v8 and Microsoft but I have proof-of-concept browserified js apps running out of a Linux build of a 0.14 Core clone. The possibilities are entertaining: https://doc.qt.io/qt-5/qtwebengine-features.html -- and, because it's Qt and restricted to the GUI part of the wallet, adding user-appealing functionality doesn't entail any fiddling with the blockchain engine and is basically just a bolt-on. Cheers Graham
|
|
|
|
extro24
|
|
August 29, 2017, 05:15:03 AM |
|
The other issue with upgrading is Segwit. I understand it will make easy cross chain exchange with other Segwit coins like Bitcoin and Litecoin.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
August 29, 2017, 11:29:09 AM |
|
The other issue with upgrading is Segwit. I understand it will make easy cross chain exchange with other Segwit coins like Bitcoin and Litecoin.
That entails a long running jump and grab to an 0.14.2 Core clone. And a hard fork. That's quite a big “ask”. Right now, I'm trying to get a sense of the role that Datacoin's unique strorage feature plays in the overall functioning of the coin. It's PoW, so people can readily acquire coins by mining, to pay the fees to store data. It's all nicely self-contained and unchanged from the day it was launched. There's nothing to stop people from making full use of the feature. There have been a total of 4,327 data tx made since Nov 2013 during which time (/me checks) 1985959 blocks have been chained. A significant number of tx can only be classified as “noise” (dozens and dozens of entries 'W10=' and 'Broughs='). Even if this “noise” is included, I make that around 0.2% (of blocks). I'm sorting out some public filesharing space so I can publish the raw lists should anyone wish to conduct their own analysis. Cheers Graham
|
|
|
|
|
|