[ANN][SHC] ShinyCoin █First ever RAMHOG algo Pow/Pos █NO ASIC/GPU | Whitepaper

[primer-]

Ok, I just updated the github code.  I will be spending some time transitioning my nodes to make sure they signing node isn't overloaded, as it has a few thousand blocks to catch up with.  Feel free to update your nodes in the meantime, and when the signing node is ready it will spread the signed hashes throughout the network.  Then anybody should be able to run a wallet with minimal RAM requirements.  Let me know if there are any bugs or issues.

qt not compiling on linux (both centos and ubuntu 14)

/usr/bin/ld: build/sqlite3.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [shinycoin-qt] Error 1

EDIT : Fixed by adding -ldl to line 19 of Makefile :
LIBS   = $(SUBLIBS)  -L/usr/lib/x86_64-linux-gnu -lminiupnpc -lrt -lssl -lcrypto -ldb_cxx -lboost_system -lboost_filesystem -lboost_program_options -lboost_thread -lQtGui -lQtCore -lpthread -ld
l

Daamn, such contribution..

[sunnyprince]

Ok, I just updated the github code.  I will be spending some time transitioning my nodes to make sure they signing node isn't overloaded, as it has a few thousand blocks to catch up with.  Feel free to update your nodes in the meantime, and when the signing node is ready it will spread the signed hashes throughout the network.  Then anybody should be able to run a wallet with minimal RAM requirements.  Let me know if there are any bugs or issues.

qt not compiling on linux (both centos and ubuntu 14)

/usr/bin/ld: build/sqlite3.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [shinycoin-qt] Error 1

EDIT : Fixed by adding -ldl to line 19 of Makefile :
LIBS   = $(SUBLIBS)  -L/usr/lib/x86_64-linux-gnu -lminiupnpc -lrt -lssl -lcrypto -ldb_cxx -lboost_system -lboost_filesystem -lboost_program_options -lboost_thread -lQtGui -lQtCore -lpthread -ld
l

Daamn, such contribution..

A useful post?  I am surprised.  Thanks, that wasn't an issue because of these changes but good to know for the future.

[sunnyprince]

My transition node has signed the hashes up to block 360 900.  This will be the last time in the history of Shiny that a sync takes this long.

[laxori666]

I re-compiled the windows wallet, no issues. I turned it on and it didn't crash (that comp doesn't have 16 GB of RAM), no blkindex.dat error, etc. It found 5 connections but it still didn't sync, was stuck at 0. And I got that message "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."

[sunnyprince]

I re-compiled the windows wallet, no issues. I turned it on and it didn't crash (that comp doesn't have 16 GB of RAM), no blkindex.dat error, etc.

Good!

It found 5 connections but it still didn't sync, was stuck at 0. And I got that message "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."

It can't sync yet, I haven't put the hash-signing node on the network yet, I will when it has caught up probably in 2-3 hours.  The warning, as it says, "Wait for block chain to download".  Will you be here in a few hours to test when signed hashes are in the network?

Also if anyone has any nodes which accept connections, please update them now so they propagate the signed hashes once the hash-signing node is up.

EDIT: Again if you have the RAM, your config should look like this (once you are synced):

Code:

gen=1
ramhogthreads=<n>
usesignedhashes=0

This way your node verifies the proof-of-work hashes itself.  But still it will relay the signed hashes so that nodes without the RAM can still be in the network.

[laxori666]

I re-compiled the windows wallet, no issues. I turned it on and it didn't crash (that comp doesn't have 16 GB of RAM), no blkindex.dat error, etc.

Good!

It found 5 connections but it still didn't sync, was stuck at 0. And I got that message "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."

It can't sync yet, I haven't put the hash-signing node on the network yet, I will when it has caught up probably in 2-3 hours.  The warning, as it says, "Wait for block chain to download".  Will you be here in a few hours to test when signed hashes are in the network?

Ah okay, makes sense. I don't know if I'll be here, probably not, but here's the binary.

[primer-]

New wallet synced.

[sunnyprince]

New wallet synced.

Good!  Was that the windows or you compiled yourself?

The network was settling down, so it took longer than it should.  Try it again, it sync 250 blocks per second now.

Also please update any nodes you have.

[primer-]

New wallet synced.

Good!  Was that the windows or you compiled yourself?

The network was settling down, so it took longer than it should.  Try it again, it sync 250 blocks per second now.

Also please update any nodes you have.

Linux qt wallet, new block propagation seems instant! Why is bitcoin not doing this ? Is there a centralized node that has a list of hashes ? If so can it be decentralized ?

I'll compile windows wallet in the morning, mingw wont compile using standard deps.

Working nodes :
addnode=144.76.238.233
addnode=144.76.238.235
addnode=144.76.238.236
addnode=144.76.238.237
addnode=144.76.238.239
addnode=144.76.238.242
addnode=144.76.238.243
addnode=144.76.238.244
addnode=144.76.238.245
addnode=144.76.238.195
addnode=144.76.139.106
addnode=144.76.139.107
addnode=144.76.139.108
addnode=144.76.139.109
addnode=144.76.139.110
addnode=144.76.139.111

[laxori666]

New wallet synced.

Good!  Was that the windows or you compiled yourself?

The network was settling down, so it took longer than it should.  Try it again, it sync 250 blocks per second now.

Also please update any nodes you have.

Linux qt wallet, new block propagation seems instant! Why is bitcoin not doing this ?

ShinyCoin is best coin!

[utrecht]

@sunnyprince: getnetworkhashpm is a very useful addition too.

Is that only a linux tool?  Can the hpm be posted on the block explorer?

[utrecht]

You can check it from the qt wallet as well:

Help > Debug Window > Console

Type in the command line: getnetworkhashpm

Did that exist on the previous qt wallet?  I didn't notice that was there

[baigreen]

great work dev!!
I will update chinese trahslation hours later.

Now what we should do next :
1 website
2 exchanges

[Bleeckerpub]

The solution I found is to assign a hash-signing private key.  The node who owns this key verifies that the ramhog hash for a particular block is accurate, and then signs it.  Any node that trusts that key uses the signed hash instead of computing it itself.  All nodes propagate these signed hashes so that they are easily accessible.

Some quick questions. Sorry if I am missing something here:

Is there one hash-signing private key shared by all nodes (A) or each node generates its own priv key (B) or is there a single node with the capability to sign (the only node with the priv key) (C)?

In case A: What would happen if someone infected the network with many nodes using a different priv key?

In case B: Shouldn't there be a web of trust for all those priv/pub keypairs? I guess this web of trust should be built outside of the p2p network. Each node should sign the public keys of the nodes it trusts.

In case C: Doesn't such a centralized infrastructure make the network vulnerable to ddos attacks?

After reading more carefully, I think there is one node with signing capability (has the priv key). Making it decentralized would be complicated. Here is a quick idea how it could be possible.

We would have to utilize two keypais, one used to verify hash signatures and another used to verify nodes. So:

Keypair A

privA: (not secret, shared by all nodes, used to sign hashes)
pubA: (not secret, shared by all nodes and clients, used to verify hash signatures created by privA)

Keypair B

privB: (TOP SECRET, used to sign the pubA of nodes OFFLINE)
pubB: (not secret, shared by all nodes and clients, used to verify signed pubAs)

So, before a hash is accepted by a client as trusted, the chain of verifications would be:

1. client uses public key B (pubB) to verify the signature on public key A (pubA) of the node, which has been created by private key B (privB). => Success -> node is a trusted node of the network. In other words, the node's pubA is verified as authentic.
2. client uses public key A (pubA) to verify the hash signature created by private key A (privA) => Success -> hash is trusted

The big problem is where private key B should be hidden safely. This key is the root of all trust in the network.

Anyway, just an idea. Written quite fast. I hope I haven't written anything stupid.

Corrections are welcome.

The hash signing can happen anywhere (unknown to an attacker) and there can be more than one hash signing node using the same privkey to sign, so DDoS doesn't seem to be the issue.  If you're going to have an algorithm that takes forever to verify and now you're taking shortcuts something has to be relied upon to verify for you.  Maybe have all the active nodes sign, and have the nodes instant-ban a node that signs something invalid.  The default ban times on shiny are very harsh so someone would need many unique IP addresses to even mildly annoy the network for a very short period of time.  It would be better if there was a financial penalty for signing something invalid but I'm not sure how something like that can be implemented.  Maybe each block the winner gets to sign, and forfeits his block reward (and gets banned) if his hash verification is invalid.

[primer-]

OK, whats next in terms of development ? I vote for anonymous transfers!

[Bleeckerpub]

I think in the end you will still have to invent a way for the nodes to trust each other so as to be sure about what is valid and what is invalid. I'm not sure this is possible by re-using the keypair that is used for signing/verifying the hashes, unless I am missing something here...

Why not?

[sbgyuff520]

And could someone bring me a ShinyCoin Wallet?
Can't find a place to download

win 64

[Bleeckerpub]

And could someone bring me a ShinyCoin Wallet?
Can't find a place to download

win 64

Its on the opening post ... Windows binaries

[sbgyuff520]

Who can give me a address which can download the wallet？

[laxori666]

Who can give me a address which can download the wallet？

https://www.dropbox.com/s/chgg78pxys7lodh/ShinyCoin-Qt-Win64-v0.3.0.zip