What are the futures plans? Would like to know  We are working currently on step one of the roadmap, for traders this is not exciting but miners it is Joincoin isn't designed to be mined then dumped, it is a long term project and the block rewards are positioned to award those who hold with value and growth. - Create a large network of Pools facilitating all algorithms; which in turn should make for the best mining distribution Crypto currencies have ever seen.
- Purchase Asic miners and mine BTC to automatically convert into Joincoin (perpetual buy support)
- Create a working relationship with Moolah or Coinkite (vendor support)
- Work with industry leaders to use our blockchain for anonymous businesses/contracts/services as a means to extend
Joincoins' longevity. We all know blockchain technology is the real future in this industry and we intend to take full advantage before the rest of the world wakes up.
One use we are considering is using Joincoin for decentralized trust-less voting it is up to marketing to deliver this to the public and gain approval.
edit: One option I would like to see is a merge mining co-op with another development team in the future as well. We are open to offers from other dev teams in this matter, please PM us. You should also consider a hard fork for fixing the chain reorganizations between multiple algos. Let me know if you need help... or you can read my posts about it and how they fixed it in the myriadcoin thread good luck gatra |
|
|
|
from main.h: const int64 nBlockAlgoWorkWeightStart = 99999999; // block where algo work weighting starts
int GetAlgoWorkFactor() const
{
if (!TestNet() && (nHeight < nBlockAlgoWorkWeightStart))
{
return 1;
}
if (TestNet() && (nHeight < 100))
{
return 1;
}
switch (GetAlgo())
{
// work factor = absolute work ratio * optimisation factor
case ALGO_SHA:
return 1024 * 4;
default:
return 1024 * 4;
}
}
no algo work weighting? so one sha block can orphan 1000 scrypt blocks? didn't you learn from myriad? |
|
|
|
My hypothesis is that it's easier do an attack when the difficulty is unusually high. Am I wrong in the assumption that it's easier to find 10 x 10k shares than 1 x 100k share? Or is it equally likely?
It should be equally likely. I made a quick simulation and it confirmed it: 10 x 10k takes the same time (in average) than 1 x 100k. I'm still convinced that the easiest way to exploit the broken difficulty is when it's too low. The easier way to see it is like this: if difficulty is too high for the 8 sec target, then it works like a coin that has a longer target time between blocks, so the problem is momentarily alleviated. However when difficulty is too low it works like a faster coin, "embiggening" the problem of having 8 secs between blocks (because you now have 4 or less), making it easier to exploit. |
|
|
|
Unat accepts the longest, valid, chain as the 'winner'. Not the one with the highest difficulty. (I may be wrong - I looked at the source for this, and only saw 'longest valid' - I'm, as always, willing to be corrected if I'm wrong, but this is what actually happened in the attack)
...
This is, in fact, what happened in the attack. I ignored other generated blocks, forced the difficulty down to a very low level, mined along there for a bit, and then stopped.
I think it works like all other coins, using the one with most work: see in main.cpp it accumulates the values of GetBlockWork() in order to get the work of a chain, and uses nChainWork to select the best chain, so it's not the longest. On any coin it's possible to (relatively easily) create a parallel chain with more blocks, but unless you achieve >50% hashrate your chain will not be accepted, it will be orphaned. I see it is a common mistake to believe the longest chain is accepted, while it's actually the one with more work. So I think the way to exploit the wacky difficulty ajustments is to take advantage at the time when blocks are comming faster than 8 secs, because that's when the most network hashrate is wasted (orphaned) and you can do your attack with much less than 50%. The only thing I see being an issue for UNAT so far is a large blockchain to download. Looking at the explorer, it seems like there were already a few significant attempts to disrupt the coin, but I don't see any damage done at all
damage may not have been done, and the attack may need to be refined, but it doesn't mean that it's not vulnerable. Think of what happens on instamine: if a few nodes with relative high hashrate and relative low latency generate blocks faster than what it takes for nodes that have more latency to propagate their blocks, then those few nodes can control the blockchain regardless of the hashrate %. 8 secs is too close to the propagation time, moreover if difficulty adjustments do not cope well with block time variance, it can temporarily go lower than 8 secs making it worse. |
|
|
|
|
hi!
Of course 8 secs is too low, but seeing the atack really happening would be very interesting!
I agree that the attacks 1 and 3 that you describe are enough to say the coin is insecure, however I'm not sure I understand attack2...
The accepted chain is the one with more work (accumulated difficulty), not the one with more blocks. So if difficulty skyrockets and you fork before that, I don't see how you can take advantage of the unaccurate difficulty... high diff means each orphaned block throws away more power, but there would be less orphans. OTOH, when diff is too low there will be more orphans but each one would throw away less hashrate.
Either way you compete against the network's combined hashrate... how can the inaccurately high difficulty be exploited? The relationship between orphaned hashrate and difficulty is not linear, but I think it should be easier to attack when - because of variance or "luck" - the difficulty is too low instead of when it's too high...
regards!
gatra
|
|
|
|
edited the OP: added the 's' in https://chainz.cryptoid.info/ric/also added the brand new pool: http://ric.nonce-pool.com/has the telnet forked? oh no! that would be sad this is my info: getinfo
{
"version" : 90200,
"protocolversion" : 10070001,
"walletversion" : 60000,
"balance" : 0.00000000,
"blocks" : 4544,
"timeoffset" : 0,
"connections" : 2,
"proxy" : "",
"difficulty" : 304.00000000,
"testnet" : true,
"keypoololdest" : 1406916020,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}
getblockhash 4544
49d0b46215885875860c80950f6bce57fb396036d615e038326537184bd155b4
getblock 49d0b46215885875860c80950f6bce57fb396036d615e038326537184bd155b4
{
"hash" : "49d0b46215885875860c80950f6bce57fb396036d615e038326537184bd155b4",
"confirmations" : 1,
"size" : 220,
"height" : 4544,
"version" : 2,
"merkleroot" : "9f962bf96969b7a89e235279b0f6c4d0dfe7d07e3b5f268d215b8367796b7884",
"tx" : [
"9f962bf96969b7a89e235279b0f6c4d0dfe7d07e3b5f268d215b8367796b7884"
],
"time" : 1407727040,
"nOffset" : "00000000000000000000000000000000000000000000000000000003c7622161",
"bits" : "02013000",
"difficulty" : 304.00000000,
"chainwork" : "7730a838e08d3ea2400681",
"previousblockhash" : "769550091d01a22bfd969868184c0f8a15072e0d53322eb323f89c977d4a4357"
}
|
|
|
|
the miner for stratum is here: https://github.com/gatra/fastrieworks, but it still looks like a hack, pending tasks: - some code cleanup, change "connected to server using xpt" line - more robust connection error handling - investigate why it sometimes gives 0ch/s in windows but works ok in linux will ask dga to merge after my branch looks better stratum server has been here for a while: https://github.com/gatra/stratum-miningps: I only mine the testnet when I need to test stuff like this, yesterday I had 0 connections, but my node is always up. |
|
|
|
I was hoping to push out a new ARM binary, but have been running in circles looking for a problem which probably isn't mine. Testnet at a difficulty of 304 can only support a 39bit nonce which is making allowing me to make a mess of things.
I think I removed that restriction for testnet in v0.9.2 That rule is by design: otherwise there are some cases where 2 different headers with 2 different nonces could use the same sextuplet, which could lead to attacks. However that's not a problem for testnet so I decided to allow that in order to test the miners on testnet. Maybe the rule is still being enforced? Please confirm if you're using 0.9.2 regards and kudos for your work! |
|
|
|
almost there!
my b15 miner updated for stratum is finding shares and verifying them locally, but it doesn't sumbit them to the pool yet. That's the last packet of the stratum protocol that's left to implement. I'll work on it today and, working or not, will upload to github later so others can look at it (bsunau7 offered to help).
thanks for the patience, again....
hi gatra, any updates? It's working! I just got it working with the stratum server already published some time ago. I'll clean the code a little bit and upload to github tomorrow. Also the miner is based on dga's b15, and just like dga's b15, I made it work on linux but not on windows. I'll try to debug that and if I can't find the problem I'll just make a stratum version of b14 (that should be easy now). |
|
|
|
|
nah, lots of people have heard about btc but don't have access/don't know how to buy it. And there are not many places that accept btc as payment yet...
they'll keep buying usd
|
|
|
|
Any update this week Gatra?
almost there! my b15 miner updated for stratum is finding shares and verifying them locally, but it doesn't sumbit them to the pool yet. That's the last packet of the stratum protocol that's left to implement. I'll work on it today and, working or not, will upload to github later so others can look at it (bsunau7 offered to help). thanks for the patience, again.... |
|
|
|
|
Hi people!
I'm still short on time... other members of the community offered help to I'll be working with them.
My problem debugging (the code I hacked based on) dga's miner is that using Eclipse + gdb, after the mining threads are created it stops responding for a while, making debugging very hard.
|
|
|
|
if you want manipulate that coin to damage them, it needs many resources and cost you many BTC
not necessarily... how about a coin, let's call it ShitKillerCoin that is merge-mined with any shitcoin, but with the requisite that the merge-mined blocks must have no transactions (only coinbase) on the shitcoin chain? This way, while mining your ShitKillerCoin, you are damaging the shitcoin because you are finding blocks in their chain that don't process transactions, delaying their network. It would be important that everyone agrees on which shitcoin to target so hashrate doesn't get diluted in the sea of shit. Also, if mining software is "smart" and you achieve 51% hashrate you can orphan blocks with any real transactions, effectively halting the shitcoin for as long as you can agree to do so. Then you would dump your shitcoin if someone still wants them (or keep them as a trophy) and move on to the next one. Maybe some voting system could be implemented so the ShitKillerCoin protocol could enforce which is the current target... edit: (probably almost) any idea that includes actually mining or buying the shitcoins may end up being good for them, but this could really hurt them. I just read this and its pretty brilliant. The one drawback is how often are there blocks with 0 transactions? (my knowledge in this particular subject is limited). It seems it would infer that the coin isn't heavily traded, and then perhaps not worth killing. But I like the general premise of this idea. Spoetnik and a couple others would probably be on board. Shit I just ordered my first miner you can officially put me down as will have a go at it. It doesn't matter how often do they have blocks with 0 tx. The idea is that mining ShitKillerCoin will create blocks with 0 transactions in coin shitcoin regardless of how many transactions did people using shitcoin actually attempted to make. This way we ignore their transactions and jam their network. This is an attack on their etwork and if we achieve 51% and orphan blocks mined by others, transactions in shitcoin could halt completely. We wouldn't earn shitcoin tx fees, but who wants those anyway? This would work for PoW only. For PoS or PoW/PoS some similar jamming could be done, but it would be necessary to first buy some shit in order to stake. |
|
|
|
if you want manipulate that coin to damage them, it needs many resources and cost you many BTC
not necessarily... how about a coin, let's call it ShitKillerCoin that is merge-mined with any shitcoin, but with the requisite that the merge-mined blocks must have no transactions (only coinbase) on the shitcoin chain? This way, while mining your ShitKillerCoin, you are damaging the shitcoin because you are finding blocks in their chain that don't process transactions, delaying their network. It would be important that everyone agrees on which shitcoin to target so hashrate doesn't get diluted in the sea of shit. Also, if mining software is "smart" and you achieve 51% hashrate you can orphan blocks with any real transactions, effectively halting the shitcoin for as long as you can agree to do so. Then you would dump your shitcoin if someone still wants them (or keep them as a trophy) and move on to the next one. Maybe some voting system could be implemented so the ShitKillerCoin protocol could enforce which is the current target... edit: (probably almost) any idea that includes actually mining or buying the shitcoins may end up being good for them, but this could really hurt them. |
|
|
|
Hi riecoin community, what service/services do you think this coin needs to make it more valuable?
the more the merrier! The most important service would be more pools. Then it could be online wallets, payment processors, blockchains with api like blockchain.info.... |
|
|
|
And the answers are.....?
1. Does this coin have a true difficulty rating, like pretty much every GPU mineable coin?
yes, all coins have a difficulty rating. You can see it in realtime here: http://api.riecoin.org/difficulty.phpcurrently it's 1448 2. I see it is traded on MintPal, where I already have an account, currently at a rate of about 40,000 Riecoin to one Bitcoin.
That's not a question, but yes, it is traded at Mintpal. List here (as seen in the OP): - https://www.mintpal.com/market/RIC/BTC- https://poloniex.com/exchange/btc_ric- btc38.com: http://www.btc38.com/trade.html?btc38_trade_coin_name=ric- comkort3. What's my profit potential with a few CPUs? I have an i3-4130, a Sempron 145 unlocked to dual core, a quad core AMD (i forget what it is), a 3.40 Ghz Pentium-D dual core, and a dual core Celeron, like a G-550.
That's not enough info to estimate profit, and I can't give you any guarantee. I'd encourage you to try and see for yourself. 4. Is this coin mined in pools, or is everyone a solo miner? If it is in pools, link me the list of pools.
Pools (as seen in the OP): - http://ypool.net/ (xpt) - ric.upcpu.com (xpt) Thanks for your interest and good luck! |
|
|
|
Thanks for keeping up the development, Gatra. Sent 4000 RIC from the miner dev fee to you.
7f1beed387890b0d2f56cf9768cb1b346d982ef08b76c86029e29b4ea3b86e9b
(Posted publicly so people know where their miner dev fees are going.)
(btw - if you're taking votes: I wouldn't change the PoW even if the GPUs hop on it. I think the cool thing about Riecoin is the fact that it produces something mathematically interesting, and it's not worth sacrificing that in the pursuit of a philosophical goal as questionable as being "CPU-only".)
thanks! Of course the PoW is the heart of Riecoin and what sets it apart from the rest, I wouldn't change that. However I am thinking of making the nonce field 512bits instead of 256. That would give room for more optimized mining and allow us to mine larger sextuplets. What do you think? My quick estimation says mining could go about 5 times faster. Is that correct? |
|
|
|
Any update this week Gatra? And how is your flu?
I'm fully recovered, thanks! it's winter down here, lots of people got sick with this weather. miner is still not working though, I'm having problems with the debugger hanging, so it's hard to debug. price is low! I have to stop constantly checking that android widget or I'll go crazy.... |
|
|
|
|
I have the feeling that you are overthinking this....
Just allow PubKeyHash tx only, and use bitcoin signed messages for claiming. And announce with some time so interested parties can momentarily send funds to a PubKeyHash if they have it in some other form.
|
|
|
|
well, you were wrong about being too late to bitcoin: 2011 was not late after all regarding arimaa... I think one workable solution lies somewhere between these. Allow the user to play both players, but only to move certain pieces. Require that a forced mate be done not only in a certain number of moves, but with a particular piece. (Either a specific rabbit ftw or an elimination/immobilization sealed by a specific piece's move.
it could work, but I wish it could be made more similar to actually evaluating the best move for a postition... well, all this is very interesting, but eventually I'll have to get back to work.... I'll think about tetris and I'll research the foldit thing. If it has a scoring system then it could be used for the difficulty function. If you're interested we could work together on that. It may very well be that the bitcoin blockchain is the first "immortal construct" in our known universe.
but not yet... an asteroid or supernova and we're toast, but we are getting there  And regarding Marvin, I have to say he's the best AI. Ever. I prefer him to my other favorites, Mr. Data (even Lore), Bender, HAL or any other. I always had the thought that maybe there were many sentient AIs but they got depressed and decided to kill themselves. |
|
|
|
|
Show Posts
