One of the things I noticed with gapcoin is that the time between blocks isn't monotonic (regular). This seems to cause significant issues (at least for me) with the wallet as network elements (NAT) drop connection state without the end nodes knowing, so you get 45 minute "hangs" while you re-transmit packets to "dead" peers.
I hope that the "slow block" which a super block will generate doesn't have a de-stabilizing effect on the network.
Regards,
--
bsunau7
well, when ypool was down we saw that there was a long time without blocks, but when block generation resumed all pending transactions were included and clients resumed working without problems; so it looks like we tested this scenario. it could be another problem with gapcoin we'll see in a couple of days: superblock expected this weekend! |
|
|
|
I AM prepared to lose this money so if either of these coins fail it wont bother me and I am planing on holding them for years. Help me gamble guys!  Whatever you choose, don't just hold for years. A lot happens in a few months, let alone years! You may want to choose some innovative ones and regularly (not yearly) look out for clones overpassing them (like LTC did with Tenebrix?) |
|
|
|
Yes, the superblocks will have higher difficulty and the record holder would have the highest, however if more than one of them share the same top difficulty you'll have to decide by comparing the value of the hash of the block's header (in the bit order that is used to generate the base prime), or just compare the base prime for those.
Hi gatra, do we have to roll the timestamp as frequently as before with the new super block stratergy? Hi! Yes: maybe less frequently because larger numbers mean that looking at all the nonce space may take a little longer, but most likely the difference will be too small to be noticed. |
|
|
|
But weird thing is, that my wallet didn't sync any further and the blockexplorers too. Let's hope it doesn't happen again  I noticed the same thing. My wallet was not synced for nearly 14 hours but my miner kept running and submitting shares. I watched both the miner and my wallet move on to the next block at nearly the same time. This is because there were no mined blocks for 14hs. There were no blocks to sync. |
|
|
|
No, the micropayments will be on-chain! Precisely the reason that this system uses zencoin instead of bitcoin or othercoin is because it will require a chain specifically oriented toward facilitating continual micro-payments for accounted resource.
Hi HunterMinerCrafter! Your connection to this coin makes me have more confidence on it, however I see lots of aspects that are not yet clear and still undefined. I still wouldn't put my money on it. See this: 8. The micropayments algorithm assures a frictionless (no fee, off-chain) transfer of coins every few seconds or even less.
Another concern is how would the reputation system work. Best regards! Gatra |
|
|
|
interesting, but if people put their computational resources for hire, then those won't be available for securing the network (ie calculating POW), and vice versa. So there may be a conflict that jeopardizes the security of the network....
what? did you say delegated pos? get out...c'mon... really?
will be happy to discuss the coin infrastructure. so, why not dpos? in addition, this contradiction is 'virtual' in case where tx fees are most (or all) of the incentive dpos has the drawbacks of pos while adding centralization. If you had PoW, I see many cool forms of arbitrage happening: being a provider and "outsourcing" to cheaper providers, using coins to pay a provider to mine coins for you, etc. The coin is degined for micropayments. I'm not sure (yet don't know) if it'll be economic or convenient or safe for other uses. what does this mean? I can't think of any design decision that would be influenced by that, because... aren't micropayments handled off-chain? You may want a fast block generation rate, but, what else? |
|
|
|
There's one more feature we'll all want: the records! showing the largest primes so far!
I'll see if I can make a quick implementation inside the client, so you could just query it.
Will super-block report a higher than normal difficulty? If so, I could find the record-breaking blocks directly this way Yes, the superblocks will have higher difficulty and the record holder would have the highest, however if more than one of them share the same top difficulty you'll have to decide by comparing the value of the hash of the block's header (in the bit order that is used to generate the base prime), or just compare the base prime for those. |
|
|
|
|
interesting, but if people put their computational resources for hire, then those won't be available for securing the network (ie calculating POW), and vice versa. So there may be a conflict that jeopardizes the security of the network....
what? did you say delegated pos? get out...c'mon... really?
|
|
|
|
|
I forgot to mention that there can be more than one active alert at any given time, but only the one with highest priority is displayed in the status bar of the QT client and shown in the getinfo rpc.
And of course, thanks for updating the chain explorer. There's one more feature we'll all want: the records! showing the largest primes so far!
I'll see if I can make a quick implementation inside the client, so you could just query it.
Thank you,
Gatra
|
|
|
|
oops, yes, I made the alert general and not specific to versions prior to v0.10.2
I guess I should cancel it and generate another one
Good testing for the alert system then  I've reflected the alert on the explorer home page, but this makes me wonder if there could not be two "errors" message instead of one. * errors: would be same as current, specific alert updates, problems with the daemon, etc. * alerts: would hold general alert messages/messages, not specific to your daemon. The alerts could be reflected in the explorers and websites, and be a way for the dev ( you ) to push news in a widespread fashion. I think the priority field of the alerts is made for this purpose. It's odd that the getinfo rpc shows them as "errors" instead of "alerts", but alerts can have a start and an end time, a priority, and can be made to target specific client versions or general. So, a low priority, general alert, could be used to push news... but for not important messages twitter is just more user friendly |
|
|
|
yay! the alert system works! I just broadcasted and alert.
Hmmm, I'm on 10.2 and still seeing the alert is it normal? {
"version" : 100200,
"protocolversion" : 10070001,
"walletversion" : 60000,
...
"errors" : "URGENT: upcoming hardfork. Update to v0.10.2 before Nov 8, 2014"
}
oops, yes, I made the alert general and not specific to versions prior to v0.10.2 I guess I should cancel it and generate another one |
|
|
|
|
Another thing to consider:
If expected average merit and max merit depend on the size of the primes, wouldn't I get an advantage by mining a pool using smaller primes? (restricting myself to smaller "shifts") Smaller primes mean faster computations, so more chances of getting a share, but at the expense of less changes of getting an actual block!
If this is true, then pools would have to someway incentivize larger "shifts".
|
|
|
|
|
Hi!
A couple of questions: doesn't proof of work verification necessary involve testing all numbers in the gap? Even using a sieve, wouldn't it become too slow?
If merit is about gap size/log(p), but max gap size is O(log^2(p)), then max merit is O(log(p)). So in order to get more merit, you'll eventually need larger primes, otherwise you'll have an upper bound for the merit! How do you handle this?
I'm really interested in seeing how would this work.
Best regards,
Gatra
|
|
|
|
|
Now that the discussion on side chains is more advanced, it looks like a side chain with faster block times could help with this. If it's merged-mined with bitcoin then it could be secure enough for smaller and faster tx.
You would have some money for everyday use on the fast side chain.
|
|
|
|
|
yay! the alert system works! I just broadcasted and alert.
|
|
|
|
Hi people! the update is ready! This is a mandatory update because of a hard fork required for the new superblock feature. Please update to v0.10.2 before Nov 8th. Sources are in github ( github.com/riecoin/riecoin) and binaries in sourceforge ( https://sourceforge.net/projects/riecoin/files/riecoin%200.10.2/). Block 156672 will be the first one that breaks the old protocol, and 156816 will be the first superblock. From then on, superblocks every 4032 blocks (one week). |
|
|
|
|
Show Posts
