Topic: Re: [AXIOM] AxiomMemHash, Schnorr Sigs Implemented, APOS 3.0, AXH 2.0 Proposed - page 2. (Read 204903 times)

Ok so maybe they do get written. But nonetheless the thing still works just fine.

The code only checks hem at connection handshake, nothing checks that the actual block data file matches.

Which is just as well considering with several coins we built we decided later what handshake to use after well already had an active blockchain.

(For example with DVC and GRP and such we had those four bytes be human-legible saying GRP: or DVC: or whatever, maybe grp: or dvc: for the testnets).

Heck when we first started building GRouPcoin and DeVCoin we didnt even jknow about the thing, we came across it when we started looking into how to make sure we didn't connect to alien coin-daemons.

-MarkM-

Yah magic bytes. Few bytes taken from the end and few from the start of a key give u the magic. Bytes are on the left and on the right and magic, magic dancing inbetween. I heard about them when i was a trucker and since have ever wondered why are they added to the OP of a shitcoin. My take was its some winning bytes u can find somewhere in the code and exchange for a prize. Prize must differ from coin to coin, I thought. With one coin, its a kick in the arse, with another coin its eye cut.

Just open the blk0000.dat file with hex editor. Look the first 4 bytes. 

Not true. The magic bytes are just a handshake upon connecting, to ensure you are connecting to the daemon you expect. They do not go into the blocks nor blockchain.

They do however seem to go into the peers.dat, so your old peers.dat will be thrown out since it is a list of peers that use the old handshake thus a list of peers you don't actually want.

-MarkM-

If you change the magic bytes, you cannot read the current block files!

That's strong.  Thank you.  I have a grip of Axiom and a 64 core powerhouse computer that was used for some CPU coins.  This is a lesson that just about every coin can be GPU -> FPGA -> ASIC  Its just evolution.

Well the chain definitely forked horribly and quite long ago.

Thus we have gone with it, making an actual fork, so that all those folk who are on the big alternate chain everyone in the Galactic Milieu is using don't have a huge mess of accounting screwups.

The fork is named Axon, its default ports are one higher than Axiom's so that it uses different ports, and one of the magic bytes is different too so it won't connect to Axiom instances even if it does encounter one.

It is at https://github.com/knotwork/axon

The node to add to synch with its blockchain is dvcstable01.dvcnode.org

I cannot set my country-house's router to allow incoming connections until I physically get out there and I am not sure when that will be.

You should allow incoming connections yourself if you are able to, either by messing with your modem/router or by using UPNP.

FEED YOUR EXISTING AXIOM WALLETS TO IT because up until sometime in 2016 or so it should match the AXIOM blockchain.

THIS WAY YOU GET FREE AXON COINS in effect, corresponding to AXIOM coins you held up to whenever the fork actually happened.

-MarkM-

I withdrew over 140,000 from the exchange earlier this year and never ever saw on the blockchain the transaction they claimed they sent.

I wrote to them repeatedly for months with no results.

It was Yobit exchange and they claimed to have sent this:

FAILED WITHDRAW:
2016-04-22 01:05:48
143226.28403252 AXIOM
041aba1ba22d8fd93ff688f9be32d22eb803f460aa39f7cd31ce400f3d5dbb21

I have never yet seen any such transaction.

I run

    "version" : "v1.0.0.0-g",
    "protocolversion" : 60015,
    "walletversion" : 60000,

on several nodes and have since long ago when the coin was created.

My nodes with ports open  to accept connections are dvcstable01.dvcnode.org, crossciv.no-ip.org and ufbsh.no-ip.org though I have many others behind those IPs.

-MarkM-

No pools?

The OP says it's this one, still looks good to me at a glance: https://github.com/axiomcryptocurrency/axiom

Anyone have access to this coin's github?

axiomd getpeerinfo|grep addr|sed -e "s/\"//g"|sed -e "s/ ://g"|sed -e "s/,//g"|awk '{print "addnode="$2}'

addnode=64.71.72.56:15760
addnode=99.192.80.197:15760
addnode=68.58.2.117:15760
addnode=95.105.100.16:15760
addnode=79.172.96.207:15760
addnode=46.188.4.74:15760
addnode=193.227.134.111:15714

this new conet for node
addnode=99.192.80.197
addnode=79.172.115.95
addnode=110.146.159.175
addnode=104.172.24.79

If Yobit shows nodes somewhere I haven't found it, but TX coming through so Yobit is on the same chain as most of those peers above should be.

where it is possible to look what nodes are used by yobit.net?

I'm back at the other fork, the only connection I could tell had running the one you're on went off before I could fully sync.


17:55:51

getmininginfo


17:55:51

{
"blocks" : 862475,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : {
"proof-of-work" : 0.00000005,
"proof-of-stake" : 1830.13868891,
"search-interval" : 16
},
"blockvalue" : 250000000,
"netmhashps" : 0.00000000,
"netstakeweight" : 2223507320591.49169922,
"errors" : "",
"pooledtx" : 0,
"stakeweight" : {
"minimum" : 2167842012000,
"maximum" : 0,
"combined" : 2167842012000
},
"stakeinterest" : 1000000,
"testnet" : false
}
Oh well, given the PoS diff it's the larger one and probably means Yobit as only remaining exchange would stay on it anyway. What might've happened is someone with a mining rig came on, with that PoW diff it could generate even several dozen blocks in the first few seconds until the diff adjusts. But that's long enough for this sort of thing to rip a chain apart. Would explain why the forks differ that much in block count as well.

Yes, this could've been a nice and healthy coin if the dev side would've worked out properly, or the captain didn't abandoned ship at least. Well, it still worked out well enough for me, even with some funds going down with Cryptsy, but I do want the coins I'm dealing with to prosper.

Here are some peers of mine but be advised that some forking happened:

"addr" : "79.172.115.95:15760"
"addr" : "[2001:470:7a9c:1337:219:b9ff:feec:940e]:15760"
"addr" : "104.172.24.79:15760"
"addr" : "[2001:0:9d38:6abd:1883:30c6:9753:e7b0]:59348"
"addr" : "110.146.159.175:15760"
"addr" : "99.192.80.197:15760"
"addr" : "[2a01:4f8:120:64ae::301]:54978"
"addr" : "[2001:0:9d38:6ab8:3cb5:5e3:d1f3:7d8e]:65368"

wallet not sincron...

 my wallet is forking off again, appears that there is no longer enough hash to support the chain;

03:36:42

getmininginfo


03:36:42

{
"blocks" : 868495,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : {
"proof-of-work" : 0.00000012,
"proof-of-stake" : 298.99591880,
"search-interval" : 16
},
"blockvalue" : 250000000,
"netmhashps" : 0.00001236,
"netstakeweight" : 341130436771.26684570,
"errors" : "",
"pooledtx" : 0,
"stakeweight" : {
"minimum" : 440327998341,
"maximum" : 0,
"combined" : 440327998341
},
"stakeinterest" : 1000000,
"testnet" : false
}

 high PoS diff and getting about 1 blk/min.

going offline, it's been fun, shame on devs on vacation

Well, I'm not on that fork for sure. My attempt to switch over didn't went further than the wallet re-scanning through that January bootstrap for the last hours so I don't know if that remotely works this time.

nice, all agree


10:13:08

getblockhash 864362


10:13:09

09573fbb871921dc416403f8ff183291a03924c9d8a973fe8e697438ae82d4fb


10:17:55

getblockhash 864990


10:17:55

c46a36b5fbb822940270e7c88ad86d7bd7d981dd0c6311e90187a638fdb51aef


15:06:30

getblockhash 865170


15:06:30

d6366f6fccc30a416dfd509bcfce2cbdf89df53779f802c4bb97854c17fb9d60