And could someone bring me a ShinyCoin Wallet?
Can't find a place to download
win 64
Topic: [ANN][SHC] ShinyCoin █First ever RAMHOG algo Pow/Pos █NO ASIC/GPU | Whitepaper - page 22. (Read 58457 times)
July 05, 2014, 08:49:30 PM
July 05, 2014, 04:41:08 PM
Quote
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?
July 05, 2014, 02:06:00 PM
OK, whats next in terms of development ? I vote for anonymous transfers!
July 05, 2014, 08:00:42 AM
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.
July 05, 2014, 06:20:23 AM
great work dev!!
I will update chinese trahslation hours later.
Now what we should do next :
1 website
2 exchanges
I will update chinese trahslation hours later.
Now what we should do next :
1 website
2 exchanges
July 05, 2014, 02:10:18 AM
Quote
You can check it from the qt wallet as well:
Help > Debug Window > Console
Type in the command line: getnetworkhashpm
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
July 05, 2014, 01:48:31 AM
@sunnyprince: getnetworkhashpm is a very useful addition too.
Is that only a linux tool? Can the hpm be posted on the block explorer?
July 04, 2014, 08:26:38 PM
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 ?
July 04, 2014, 07:57:23 PM
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
July 04, 2014, 07:49:56 PM
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.
July 04, 2014, 07:39:24 PM
New wallet synced.
July 04, 2014, 05:30:32 PM
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?
July 04, 2014, 05:21:11 PM
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=
usesignedhashes=0
July 04, 2014, 05:16:29 PM
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."
July 04, 2014, 04:45:44 PM
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.
July 04, 2014, 04:38:32 PM
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..
July 04, 2014, 04:24:45 PM
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..
July 04, 2014, 04:07:50 PM
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.
July 04, 2014, 03:13:33 PM
The result will be that anybody can run a wallet without needing to run the ramhog algorithm. This will also make sync times near-instant. [...] These nodes still fully validate all transactions as usual. The only difference is they don't compute the proof-of-work hash themselves.
Nice! This should really help increase adoption of the coin. I will be around, I should be able to get the windows wallet up quickly enough after you update the code. July 04, 2014, 03:04:17 PM
Awesome work. So only if ramhogthreads=0, it will use the signed hashes?
That's how I had it initially. However, if I do that then syncing will still be slow for someone who is checking. I am leaning towards having the default be true. Then a miner has two choices after adding "-gen=1": either add "-ramhogthreads=n" or add both "-ramhogthreads=n" and "-usesignedhashes=0". The former, they will sync quickly and mine, the latter, they will sync slowly and mine. Or they can leave it on for the initial sync, then change the setting again. A miner will have to be comfortable with changing config files anway. Any thoughts? Jump to: