[ANNOUNCE] RuCoin - Russian alternate cryptocurrency - exchange is up already!

[markm]

Sounds like they "enabled" one-sided merged-mining simply by hacking the next-gen Bitcoin.

It is pretty trivial, just change the visible to user occurences of the word bitcoin, optionally, if you happen to care at all about such cosmetics, its the hardest part of the whole hack so why bother, and change the handshake bytes (if they even bothered to do that or even realised such a thing exists) and the IRC channel (and optionally IRCserver/network), the genesis block, the genesis block hash check asserts, and the default port numbers.

I have done it umpteen times in the process of prototyping and testing Britcoin, Botcoin, Canadian Digital Notes, CZech Bitcash, GMC, GRF, UNS and so on and so on.

Since bitcoin still only has one-sided merged mining, they inherited that. They didn't bother to apply the merged mining patches used to make namecoin, devcoin, groupcoin, ixcoin, botcoin, britcoin, etc etc etc able to be auxiliary chains.

As civilisations calling themselves Russians have been reported/encountered in the Galactic Milieu I don't see a puny two million premine as much of a problem, most nations pre-mine all their coins, I guess in Freeciv terms the government type of these Russians might be "Communism", it seems very socialist of them to kindly share most of the coins with others instead of hoarding the whole lot in their "central bank".

Unfortunately only having such a small amount of their currency in their own hands would somewhat restrict their ability to buy into all the other nations' currencies on the kind of scale the other nations have been accustomed to but hey, maybe they can spin it as the other nations being capitalist pigs not real democracies at all...

One might as well start one's hacking from the very latest Bitcoin code, so as to include the BIP-30 security fix for example. I wonder if multicoin is that up to date, maybe multicoin would be the easiest way to get up and running?

-MarkM-

[1714190475]

1714190475

[1714190475]

1714190475

[1714190475]

1714190475

[markm]

Okay, I have made a version that has merged mining enabled. I based it on GRouPcoin code, so it also includes the BIP-30 patch.

It is at https://sourceforge.net/projects/galacticmilieu/upload/RUCoin/

If you don't get connections, make sure you have incoming port (default is 8883) open and private message me your IP address and I will add you with -addnode.

-MarkM-

EDIT: Oops, minor glitch, I forgot to change its aux-chain=ID to 0x0007. Done now and re-uploaded.

[Kumala]

All we need is the developer to accept this "new" version and a merged mining pool supporting it.

[markm]

All we need is the developer to accept this "new" version and a merged mining pool supporting it.

Well lets make sure it works first. I do not see any additional connections yet, how many connections do you have?

-MarkM-

[Kumala]

Shows 1 connection for about 30 seconds, then 0 connections. Doesn't download any blocks either.

[tiker]

Shows 1 connection for about 30 seconds, then 0 connections. Doesn't download any blocks either.

Sounds like the same behavior I saw where a 4.x client was connecting to a 5.x client.  They're incompatible with each other and drop showing 0.  After awhile though, my 5.x clients did find other 5.x clients on the internet to connect to and held those connections.

Which version is markm's build based on?

[markm]

Mine is based on the only one that had source code available.

DIdn't I mention that if you don't get connections please private message me your IP address so I can use -addnode to have mine reach out to you because I have no incoming ports? If you too have no incoming ports oops no go. But if you do have incoming ports yet others are not reaching out to you once they see you in the IRC channel, this method of having others add your IP using -addnode can work around that.

Once I make sure it works, I can build based on Bitcoin 0.6 code (master branch at github) to bring it nicely up to date.

-MarkM-

[tiker]

Here's what I'm trying to figure out:

Client 4.x does not connect to  client 5.x.

Sources on the site are 4.x (which I'm guessing is the source you've modified), binaries on the author's site are 5.x.

Since 4.x clients can't connect to 5.x clients, doesn't that essentially make 5.x clients a new fork of the chain?  The 5.x clients will never see what 4.x clients do unless the author has a bridge to link the two somehow...

If your code is based on the 4.x client then I'm guessing it works with the author's 4.x clients.  Which is the correct fork - 4.x or 5.x?

If you do port it to 6.x code you'd have to figure out which official client it's compatible with.

But that leaves the question of:  Which fork is the (author supported) official client?

I'd run some tests with transactions but I don't have any RUC to send around for testing.

[markm]

Well from the look/sound of it, one is an open source branch the other is a closed-source / proprietary fork.

Which do you want to work with, open source cryptocurrencies or proprietary ones?

-MarkM-

[tiker]

Obviously the open sourced version but it's not up to me to decide.

I'm waiting to see if the forums on the rucoin site come back to see what it says there about the two versions.  Its possible that the binary versions are still being worked on and the source may come out soon.  The 5.x binaries on the site were put there sometime in the last 2 months.

[markm]

I expect that what we need to know is what sequence of four bytes they changed the handshake to.

It makes sense that they changed it, because the older version - the source code - used the exact same handshake bytes as bitcoin does, meaning it would actually connect to all the bitcoin daemons whose addresses it would have gotten from DNS and so on, and actually try to fit their blocks into its blockchain, and actually send bitcoin daemons its blocks and so on.

So it makes perfect sense they will have changed the handshake. The very first attempts to make GRouPcoin/DeVCoin we realised that had to be changed. I have changed it in this test of trying to implement proper merged mining, I changed it the way I have in other altcoins, a way that makes it easy for a human watching the packets to see at a glance which chains are trying to talk to each other: I am using "RUC:" for main net and "ruc-" for test net, just like GRouPcoin uses "GRP:" and "grp-", DeVCoin uses "DVC:" and "dvc-" and so on.

Once we are sure it works we can always change the handshake to whatever they want to use going forward; I didn't have any qualms about changing it since it is obvious from the fact their new proprietary version also changed it thus that going forward it is not going to be the same as bitcoin's handshake like it was in the 0.4 version the source code is for.

If you are into wireshark or ethernet sniffing or whatever, maybe for you it is trivial to find out what four byte sequence their new version does use, in which case we can easily adapt. And since I do provide source code, you can easily adapt it yourself to check that it really is using the bytes you think it is using.

-MarkM-

[tiker]

I can run a packet sniffer to find out but I need to run some tests to see how it'll appear.

Where in the source code is the handshake id set?  (Groupcoin as an example)

[tiker]

Ok, lets see if I got this right...

bitcoin and rucoin v4.x is using the magic id of D9B4BEF9 (sent as F9 BE B4 D9)  from https://en.bitcoin.it/wiki/Protocol_specification

If this is the code you're looking for then the rucoin 5.x binaries is sending across the wire "FA BF BA DB" reversing to become the magic id of DBBABFFA....

If I'm completely off.. let me know. 

[markm]

OK I changed it for main net to the magic ID you say above, and to the reverse, and neither got me connections in a short time.

I am using

char pchMessageStart[4] = { 0xDB, 0xBA, 0xBF, 0xFA };

again now for a longer trial as it has to flop through many many addresses that have no one at them at all it seems.

Is it still using same port number, even? (8883)

-MarkM-

[tiker]

Ok, give me a few minutes to test some stuff here.

I'll compile your version with the new magic ID, force it to connect to my windows box and will see what it puts onto the network.

[tiker]

Here's what I did:

Magic code set to:

Code:

char pchMessageStart[4] = { 0xfa, 0xbf, 0xba, 0xdb };

I set the characters in order as I see them on the packet sniffer because looking at the bitcoin source code, they are in order and not reversed like that website I linked previously shows.

Compiled, ran with addnode= windows ip


Windows box is running the 5.x binary from rucoin website.

Packet sniffer running picked up the same magic code in the same order as above which is good.

However, the new client didn't hold the connection.  It dropped but did connect to two other hosts (one using port 8883 and one on port 8333).

I also noticed that running the compiled linux binary from the website is also acting up now.  I noticed one of the binaries dropped about 2000 blocks out of the linux chain so I'm going to wipe it out and start over.

Testing continues....

[tiker]

Wiped out the block data to try and download clean with the customized version but it won't connect to anything...

From the debug log:

Code:

trying connection 192.168.50.51:8883 lastseen=-342135.4hrs lasttry=-369913.2hrs
ThreadRPCServer started
connected 192.168.50.51:8883
sending: version (85 bytes)
socket closed
disconnecting node 192.168.50.51:8883

This is my windows box running the 5.x binary from the site.

Packet sniffer shows the connection and a couple of tcp packets back and forth.  The data packet with the version information is sent and rather than a "verack" response, the reply is a disconnect packet.  So while we are sending the same magic code that the pre-compiled binaries send it's still being rejected.

[tiker]

The precompiled linux binary doesn't seem to get far enough in a connection to send the data packet with the magic id..

From the debug log:

Code:

connected 192.168.50.51:8883
socket closed
disconnecting node 192.168.50.51:8883

Which means the Windows binary and Linux binary connect differently...

[tiker]

Well.. I'm taking a break from this for this evening.. I'll do some more tests tomorrow evening if I get a chance (if my wife will let me).

Last note though...

Windows connecting to linux (custom build from your source) doesn't work... connect attemps are made but is dropped
Windows connecting to linux pre-compiled build works.. but packets look odd compared to this page says it should go.. https://en.bitcoin.it/wiki/Protocol_specification

The pre-compiled linux binary is downloading the block chain now where the custom build wouldn't.  I'm thinking there's more to the protocol than just the magic id that needs to be looked at but that's for another day.

[markm]

One of the attempts you desribed drops connection after version is sent.

So maybe they decided they don't want to connect to their old version and simply check that the version number is not too low.

So we could try using a higher version number.

-MarkM-