We use 60 (0x3C) as the prefix for public key base 58 representations. Still 0x80 for private keys.
For future reference, where did you get these hex from? It's in the source code in the file base58.h (it's written as 60 in decimal). I decided to put that value so addresses start with R, got it from here: https://en.bitcoin.it/wiki/List_of_address_prefixes |
|
|
|
Bitcoin is 0x00 for publickey and 0x80 for the private key.
Anyone know what pub and priv key for riecoin?
What is the mainnet for Riecoin?
I need this for the android app I am working on for Riecoin.
We use 60 (0x3C) as the prefix for public key base 58 representations. Still 0x80 for private keys. What do you mean by "What is the mainnet"? this? The protocol version is hardcoded to 10070001 and the protocol's "magic" number is 0xdbb2bcfc, and 0x0511090d for testnet. |
|
|
|
Hey, Gatra -
Would it be insane to think about adding a "fast revalidate" mode to the client for startup, in which it randomly picks $k$ of the 6 primes to test for primality, and assumes that as long as nothing in the blockchain fails the check on any of those $k$, that it's probably OK to accept them and keep running?
I'm thinking just for client initial startup, obviously. Doing it randomly prevents an attacker from getting away with fake blocks for any significant length chain, and it could reduce the number of needed Fermat tests down to 2 or 3 instead of 6.
I think it's possible, not insane... Everytime you run the client it validates last blocks in the disk and then downloads any new blocks from the network. By default we are currently validating the last 288 blocks from the disk: this is done just to detect curruption and will be changed down to 7 for the next version. Anyway you can configure it using the -checkblocks option, set it to 1 and it will start much faster! For the initial download, it would be possible to randomly skip some tests. Currently we are doing too much tests: 10 rabin-miller iterations for each of the 6 candidates. I'm lowering it and maybe adding a command-line option to configure it. This will improve validation time a lot. I think it is not needed so skip tests. If it were, we could do it in the future using your $k$ idea or maybe assigning a configurable probability so each candidate of each block is tested with probability $p$ .... or some combination of that ... |
|
|
|
I'm currently testing the new client. It comes with some speed improvements, but it's a scary thing since a bug there can cause the coin to halt. I'm being extra careful.
*gulp* can you explain a bit more? Could this affect us now, with the new client not yet launched? no, no, there are no bugs that I know of! I should have used the conditional: I meant that if I introduced a bug in the new code it would be bad so I want to test the new code carefully. Current versions work fine! |
|
|
|
|
Hi people!
A small update:
I'm currently testing the new client. It comes with some speed improvements, but it's a scary thing since a bug there can cause the coin to halt. I'm being extra careful.
The Riecoin Foundation is working in many projects. Thanks!
Difficulty seems stable with a very small tendency upwards. Still expecting it to take off and break records any time.
We are almost finished creating the basis from where to grow, don't give up on RIC!
Thanks and regards,
Gatra
|
|
|
|
I think the patch is not correct. By default (the case where params.size() is 0), you should call GetDifficulty with the value of the global miningAlgo, not with 0 as the patch proposes. |
|
|
|
Doesn't seem to work here, I'm getting a syntax error line 101 (Python 3.2.3) :/ I got a syntax error on that line when using Python 2.7.5, but with Python 3.3.2 it works. Anybody with more Python knowledge can help? I'm not an expert but I think Python 2 and 3 are different languages, not compatible. You have to use the correct one or port the code |
|
|
|
Hmmm, blockchain explorer is currently stuck on block 26246, which has a single transaction, f16662cadd50ccf58b585938a25810913acb05f6adaf05ab9cbdc3f84c9ab688, which has the following single vout: "scriptPubKey": {
"asm": "7692969 OP_BOOLOR [error]",
"hex": "03a962759b44e46e064da089240f13c2c9da959816e71bba7a2a0f46ed1e8d82e9",
"type": "nonstandard"
}
Anyone knows what's up? The block crawler also goes banana when looking at it. I could just tell the explorer to ignore it and go ahead, but that sounds wrong Nonstandard transactions are, well, non-standard, but valid. In those transactions you can't determine the receiver's address. By manual inspection I think that in this particular case the script makes no sense so those 50 RIC cannot be claimed and are lost, or burnt. As a quick fix, you can ignore them. Later you can accumulate and report RIC on nonstandard tx |
|
|
|
Doesn't work for me. Trying to create a lookup address wallet on faucet to show how much are left in faucet. would something like calling the getbalance rpc of riecoind from php work for you? |
|
|
|
|
hi people!
I've been very busy these days... a couple of exchanges added support for RIC since last weekly update but I didn't find the time to update the website yet. They are in the OP though.
I'm the middle of a transition that is keeping me very busy. I quit my daily job: I'll be an entrepreneur and sometimes freelancer instead of an employee. I expect this means I'll have more time for RIC soon.
My immediate to-do list:
- new core release
- stratum miners/proxy
- and now, open source xpt pool server
And right after that:
- the paper!
- gpu miner
yours truly,
gatra
|
|
|
|
|
hi! I'm traveling so please wait until tomorrow for the weekly update
we'll have a new wallet soon!
best regards!
gatra
|
|
|
|
Hi! I have a new status update for Riecoin: I've been very busy with my (other) job, but that will change next week. Also, I met many cool people that are insterested in the project, more news soon. - RiecoinFoundation is officially open and has a very cool website http://riecoinfoundation.org/And we have 2 new exchanges accepting Riecoin: - https://comkort.com/market/trade/ric_btc- http://ex.nintencoin.com/- efforts for stratum optimized miner are still on their way, also for a xpt/stratum proxy that would allow xpt miners in RIC stratum servers - difficulty is still close to it, but not breaking world records just yet.... we need just a little push... Thanks and best regards to all! gatra |
|
|
|
It also isn't clear to me how a node calculates the best chain. If it is cumulative difficulty, without any normalisation, then what is to stop someone reversing a sequence of low difficulty blocks (e.g. Scrypt or Qubit ones, currently) by means of a single high difficulty block (SHA256D, currently)?
The SHA difficulty is independent from the other algos, so a high difficulty SHA block will not overwrite a low difficulty Scrypt block for example. Just in the last hour or so I've seen a chain of five non-SHA256D blocks (112715-112719) erased by a single SHA256D block (112715): [code edited out]How should this happen if they are truly independent? anyone want to give this a technical explanation.. maybe a simple explanation too  Dev is only one that can atm This is general block reorg (also known as a chain of orphans) it happens with a block time of 30 seconds. hell even with the 10 min block time of bitcoin it happens. In myriadcoin every algo has equal standing as each has an equal score. You can see in many POS/POW coins. POS orphans POW as POS has a higher score than its POW counterpart. Ahmed exactly! the coin is broken because a single SHA block can force a reorganization and orphan many blocks from other algos. This allows for easy double spending with minimal hashrate. Just mine SHA from the last SHA block ignoring blocks from other algos. When you mine your new SHA block, all the others will be orphaned. If there are enough to confirm a transaction (which is very likely), you can double spend. But it can be fixed using normalization. Scrypt is about 1024 times SHA. You'd have to calculate the relative weight for other algos. dev: you can contact me if you need help fixing this, I have experience with alt PoWs - I'm the developer of Riecoin (new primes PoW - currently cpu only) Someone mentioned a bounty for a technical study on 51% attacks. Is that real? where can I learn about this bounty? what do you need exactly? Besides fixing this "high diff algo reorganization attack", I have some ideas for preventing 51% attacks on a coin like this. regards, gatra Thanks for your offer. PM sent. There is a 15,500 MYR bounty for analysis. I can also put up another 15K MYR for your assistance. an idea to prevent panic: there's an easy workaround (until a new client is released): when waiting for confirmations, wait for X blocks with SHA (the one with highest difficulty by far) instead of just waiting for X blocks. So if you currently wait for 6 blocks, wait instead for 30 blocks and you should be safe ( 6 blocks * 5 algos = 30 blocks ). This would give you the same expected security in average. |
|
|
|
It also isn't clear to me how a node calculates the best chain. If it is cumulative difficulty, without any normalisation, then what is to stop someone reversing a sequence of low difficulty blocks (e.g. Scrypt or Qubit ones, currently) by means of a single high difficulty block (SHA256D, currently)?
The SHA difficulty is independent from the other algos, so a high difficulty SHA block will not overwrite a low difficulty Scrypt block for example. Just in the last hour or so I've seen a chain of five non-SHA256D blocks (112715-112719) erased by a single SHA256D block (112715): [code edited out]How should this happen if they are truly independent? anyone want to give this a technical explanation.. maybe a simple explanation too Dev is only one that can atm This is general block reorg (also known as a chain of orphans) it happens with a block time of 30 seconds. hell even with the 10 min block time of bitcoin it happens. In myriadcoin every algo has equal standing as each has an equal score. You can see in many POS/POW coins. POS orphans POW as POS has a higher score than its POW counterpart. Ahmed exactly! the coin is broken because a single SHA block can force a reorganization and orphan many blocks from other algos. This allows for easy double spending with minimal hashrate. Just mine SHA from the last SHA block ignoring blocks from other algos. When you mine your new SHA block, all the others will be orphaned. If there are enough to confirm a transaction (which is very likely), you can double spend. But it can be fixed using normalization. Scrypt is about 1024 times SHA. You'd have to calculate the relative weight for other algos. dev: you can contact me if you need help fixing this, I have experience with alt PoWs - I'm the developer of Riecoin (new primes PoW - currently cpu only) Someone mentioned a bounty for a technical study on 51% attacks. Is that real? where can I learn about this bounty? what do you need exactly? Besides fixing this "high diff algo reorganization attack", I have some ideas for preventing 51% attacks on a coin like this. regards, gatra |
|
|
|
As long as Gatra doesn't abandon this project though, Riecoin will definitely rise to the top.
I wouldn't abandon my precious! and even if I did others could continue it, don't despair. we are all expecting it to rise after stratum pools start to generate blocks and the Riecoin Foundation takes over PR. I think it wouldn't be wise to launch a full blown advertising operation until the network is healthy with many pools, but that's just a few days away. |
|
|
|
New status update: https://bitcointalk.org/index.php?topic=541647.msg5943221#msg5943221New ideas to explore: - Chebyshev's bias: is it large enough to use it for miner optimization? at first sight, it doesn't look that way, but it's effect may be amplified by the fact that we use prime 6tuples, not just primes... needs more research. Optimized miners use a hardcoded value for the remainder (or "offset") of their primorial, but is it the best value? - If we'll be hardforking to include constant difficulty adjustments, maybe we could use the opportunity to include searching for 7 or 8tuples along with 6 tuples. Best regards to all! gatra Does the stratum miner have a way for the worker thread to determine if a new block has arrived without exiting its mining loop? If so, I can throw mine into the stratum miner pretty easily at this point. "work_restart[thr_id].restart" is global and will change from false to true (for all elements of the work_restart array - ie for all threads) when a new block has arrived. Then each thread will set it to false again when it has updated it's block data struct. |
|
|
|
New status update: https://bitcointalk.org/index.php?topic=541647.msg5943221#msg5943221This week, time flyed by. But it's Thursday again (at least in some time zone it still should be) and we have some news for Riecoin: - Our website riecoin.org was updated a couple of times - A Mac OSX xpt miner was released https://bitcointalk.org/index.php?topic=446703.msg5931299#msg5931299- Riecoin Foundation is growing. Site will be up soon. - Difficulty peaked at 1712. Remember that 1857 is required in order to break the world record. As it was mentioned on the ANN thread, there are reasons to believe that Riecoin's network computing power is enough to easily break the record, but the limits imposed in order to make RIC practical as a currency as well are holding us back. This however doesn't make Riecoin less useful: we have created a repository of more than 27000 prime sextuples. - Stratum pools are still low on hashrate (or "scanrate" as I like to put it) because the most optimized miners use the XPT protocol. Ypool works fine but it's not the only pool: upcpu has already found many blocks. My current priorities: - Optimized miners for stratum protocol - work still in progress - XPT / Stratum proxy in order to use xpt miners with stratum pools - work still in progress - then comes the updated "Riecoin Core" 0.9.0 New ideas to explore: - Chebyshev's bias: is it large enough to use it for miner optimization? at first sight, it doesn't look that way, but it's effect may be amplified by the fact that we use prime 6tuples, not just primes... needs more research. Optimized miners use a hardcoded value for the remainder (or "offset") of their primorial, but is it the best value? - If we'll be hardforking to include constant difficulty adjustments, maybe we could use the opportunity to include searching for 7 or 8tuples along with 6 tuples. Best regards to all! gatra |
|
|
|
This week, time flyed by. But it's Thursday again (at least in some time zone it still should be) and we have some news for Riecoin: - Our website riecoin.org was updated a couple of times - A Mac OSX xpt miner was released https://bitcointalk.org/index.php?topic=446703.msg5931299#msg5931299- Riecoin Foundation is growing. Site will be up soon. - Difficulty peaked at 1712. Remember that 1857 is required in order to break the world record. As it was mentioned on the ANN thread, there are reasons to believe that Riecoin's network computing power is enough to easily break the record, but the limits imposed in order to make RIC practical as a currency as well are holding us back. This however doesn't make Riecoin less useful: we have created a repository of more than 27000 prime sextuples. - Stratum pools are still low on hashrate (or "scanrate" as I like to put it) because the most optimized miners use the XPT protocol. Ypool works fine but it's not the only pool: upcpu has already found many blocks. My current priorities: - Optimized miners for stratum protocol - work still in progress - XPT / Stratum proxy in order to use xpt miners with stratum pools - work still in progress - then comes the updated "Riecoin Core" 0.9.0 New ideas to explore: - Chebyshev's bias: is it large enough to use it for miner optimization? at first sight, it doesn't look that way, but it's effect may be amplified by the fact that we use prime 6tuples, not just primes... needs more research. Optimized miners use a hardcoded value for the remainder (or "offset") of their primorial, but is it the best value? - If we'll be hardforking to include constant difficulty adjustments, maybe we could use the opportunity to include searching for 7 or 8tuples along with 6 tuples. Best regards to all! gatra |
|
|
|
|
Show Posts
