error - page 25. | Bitcointalksearch.org

colinistheman

hero member

Activity: 907

Merit: 1003

Quote from: The One on April 21, 2014, 05:54:08 AM

Quote from: colinistheman on April 21, 2014, 03:28:34 AM

Quote from: The One on April 20, 2014, 05:25:24 PM

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

Well just so you know Tranz (the programmer of the new fork code) recommended giving a month advance before the new fork takes place. If you want to take that up with him go for it. But I personally respect his opinion.

A month, why?

Make no sense at all unless certain parties want this current 48 block 'KGW' to continue because they benefit from it.

3 days maximum is all you need.

You sure are full of sharp comments aren't you.

colinistheman

hero member

Activity: 907

Merit: 1003

Quote from: Ebrelus on April 21, 2014, 09:02:20 AM

Could someone create a multipool which would mine more profitable coins to sell them and earn us RPC? Maybe with 25% of RPC given randomly in lottery style? We could move RPC higher in marketcap top this way making coin more visible. Some of us have so low hashrates that normal mining is rather a waste of time while summed up can make a difference and integrate us as a community.

That's a very intriguing idea.

Ebrelus

full member

Activity: 186

Merit: 100

Could someone create a multipool which would mine more profitable coins to sell them and earn us RPC? Maybe with 25% of RPC given randomly in lottery style? We could move RPC higher in marketcap top this way making coin more visible. Some of us have so low hashrates that normal mining is rather a waste of time while summed up can make a difference and integrate us as a community.

Adrian8307

newbie

Activity: 55

Merit: 0

This is an awesome idea, I will mine for sure. Roll Eyes

The One

legendary

Activity: 924

Merit: 1000

Quote from: ctenc001 on April 21, 2014, 06:15:03 AM

Quote from: The One on April 21, 2014, 05:54:08 AM

Quote from: colinistheman on April 21, 2014, 03:28:34 AM

Quote from: The One on April 20, 2014, 05:25:24 PM

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

Well just so you know Tranz (the programmer of the new fork code) recommended giving a month advance before the new fork takes place. If you want to take that up with him go for it. But I personally respect his opinion.

A month, why?

Make no sense at all unless certain parties want this current 48 block 'KGW' to continue because they benefit from it.

3 days maximum is all you need.

3 days is not long enough to notify all pools and services. A lot of people need to make changes, and many of them are not active RPC community members so information is slower getting to them.

What pools and services? how many? about 5 at most. How many people solo mining this? maybe about 10?

3 days is sufficient.

ctenc001

hero member

Activity: 910

Merit: 1000

Quote from: The One on April 21, 2014, 05:54:08 AM

Quote from: colinistheman on April 21, 2014, 03:28:34 AM

Quote from: The One on April 20, 2014, 05:25:24 PM

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

Well just so you know Tranz (the programmer of the new fork code) recommended giving a month advance before the new fork takes place. If you want to take that up with him go for it. But I personally respect his opinion.

A month, why?

Make no sense at all unless certain parties want this current 48 block 'KGW' to continue because they benefit from it.

3 days maximum is all you need.

3 days is not long enough to notify all pools and services. A lot of people need to make changes, and many of them are not active RPC community members so information is slower getting to them.

The One

legendary

Activity: 924

Merit: 1000

Quote from: colinistheman on April 21, 2014, 03:28:34 AM

Quote from: The One on April 20, 2014, 05:25:24 PM

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

Well just so you know Tranz (the programmer of the new fork code) recommended giving a month advance before the new fork takes place. If you want to take that up with him go for it. But I personally respect his opinion.

A month, why?

Make no sense at all unless certain parties want this current 48 block 'KGW' to continue because they benefit from it.

3 days maximum is all you need.

colinistheman

hero member

Activity: 907

Merit: 1003

Quote from: The One on April 20, 2014, 05:25:24 PM

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

Well just so you know Tranz (the programmer of the new fork code) recommended giving a month advance before the new fork takes place. If you want to take that up with him go for it. But I personally respect his opinion.

The One

legendary

Activity: 924

Merit: 1000

Quote from: ProfJski on April 20, 2014, 02:27:05 PM

I thought a timestamp was part of what is hashed into the block when it is solved (together the transactions, coinbase, and nonce), and that the network already rejected timestamps that were too far out of synch. Regardless of the problems of network communication delay, The One's point seems to be: simply compare the previous block's timestamp with the potential candidate. If the block's timestamp is too soon, it's a dud, regardless of when it is submitted. Yet could you not hash a block "in advance" with the timestamp bumped safely into the 2 minute mark and submit it once the real time is reached? This is still a limitation, because you can't snowball those two minutes, the most you can do is work barely a block ahead, because each block depends on the hash of the previous block accepted at the end of the block chain.

Or am I getting it wrong?

I'm not thinking too hard about potential little forks at the end of the chain, perhaps I should be. Bloated with Easter ham and other goodies right now. Gonna lay down! Grin

Jski

My point exactly.

There is another software that has a countdown function....ie place an order....countdown 15 seconds......order placed.

SO if a block is solved, then a countdown from 120 seconds and when it reaches 0 a block is created assuming someone done the POW. If POW done before countdown reaches 0 then it is rejected.

May require new coding but i suspect the coding would only be a few lines. Cheesy

The One

legendary

Activity: 924

Merit: 1000

Quote from: colinistheman on April 20, 2014, 04:10:38 PM

Quote from: The One on April 19, 2014, 06:58:55 PM

Currently 44030
At block 44050 give out an alert warning that there will be a fix.
At block 44100 do the fork. No point in dilly dallying wasting time till block 50,000 or more.
Speed and efficiency gentleman.

There is the somewhat large task of notifying every pool, every exchange and every miner to update their RonPaulCoin software, and ensuring that it has been done before the block number is hit. It would be an impatient mistake to undershoot this and have people still running the old software resulting an old fork competing against the new fork.

Not really. Don't think in terms of how many blocks to go but in terms of how long it will take. If finding a block takes 7 minutes (for example) then it is a drag and block count goes up slowly. 24 hours is sufficient notice as it only takes 5 minutes to download and use the new wallet.

The last time you did a fork it took weeks to get there.

colinistheman

hero member

Activity: 907

Merit: 1003

Quote from: The One on April 19, 2014, 06:58:55 PM

Currently 44030
At block 44050 give out an alert warning that there will be a fix.
At block 44100 do the fork. No point in dilly dallying wasting time till block 50,000 or more.
Speed and efficiency gentleman.

There is the somewhat large task of notifying every pool, every exchange and every miner to update their RonPaulCoin software, and ensuring that it has been done before the block number is hit. It would be an impatient mistake to undershoot this and have people still running the old software resulting an old fork competing against the new fork.

colinistheman

hero member

Activity: 907

Merit: 1003

Quote from: Cryddit on April 20, 2014, 01:10:51 PM

Quote from: The One on April 19, 2014, 06:32:19 PM

Hence why i don't understand why there wasn't a fixed minimum of 2 minutes per block in the first place, hence no one would get a block every 12 seconds.

How would you make that happen? I mean, it's one thing when you can just mark off an interval anytime you want on a local system where nobody has to agree with you, but with proof-of-work, and everybody checking your solution to reach consensus, I don't see any way to create a "fixed minimum." I mean, either the target is reached or it isn't. Time elapsed doesn't affect that because time elapsed can't be checked later.

To my understanding this would not work because the timestamp can be reported as whatever the node wants to report. In the same fashion, this is how the Time Warp exploit is accomplished on the old KGW difficulty adjustment algorithm. A fake time is given when reporting a solved block.

At least that's my understanding. So, checking how long since the last block has been solved requires 100% truthful block times which isn't always the case when submitting proof of work to the network. Any node can submit any time they want with the block.

Feel free to correct me if I am off.

colinistheman

hero member

Activity: 907

Merit: 1003

We're in the middle of testing the new version right now. Anyone is free to join us in #ronpaulcoin on freenode. Big thanks to Tranz and chiznitz.

I think RonPaulCoin's value will go up once groups of 48 blocks stop getting mined nearly instantly and sold off by exploiters.

ProfJski

brand new

Activity: 0

Merit: 0

I've also got to say a few positive things:

The difficulty rate being stuck on high for the past week has meant very little coins sold on Cryptsy. Price is sitting nicely around .001 and there's a huge buy wall at .00085 -- over 1600 RPC high. This might be coincidence, or it might be data that if we can get the scarcity of the coin working as designed with a difficulty fix, we're going to see better prices.

By my count, RPC is about 20th in a field of a few hundred altcoin in terms of BTC value.

Let's fix this baby, get a precious metals link, advertise its awesome-itude, and watch RPC grow!

Jski

ProfJski

brand new

Activity: 0

Merit: 0

I thought a timestamp was part of what is hashed into the block when it is solved (together the transactions, coinbase, and nonce), and that the network already rejected timestamps that were too far out of synch. Regardless of the problems of network communication delay, The One's point seems to be: simply compare the previous block's timestamp with the potential candidate. If the block's timestamp is too soon, it's a dud, regardless of when it is submitted. Yet could you not hash a block "in advance" with the timestamp bumped safely into the 2 minute mark and submit it once the real time is reached? This is still a limitation, because you can't snowball those two minutes, the most you can do is work barely a block ahead, because each block depends on the hash of the previous block accepted at the end of the block chain.

Or am I getting it wrong?

I'm not thinking too hard about potential little forks at the end of the chain, perhaps I should be. Bloated with Easter ham and other goodies right now. Gonna lay down! Grin

Jski

Cryddit

legendary

Activity: 924

Merit: 1132

Quote from: The One on April 19, 2014, 06:32:19 PM

Hence why i don't understand why there wasn't a fixed minimum of 2 minutes per block in the first place, hence no one would get a block every 12 seconds.

How would you make that happen? I mean, it's one thing when you can just mark off an interval anytime you want on a local system where nobody has to agree with you, but with proof-of-work, and everybody checking your solution to reach consensus, I don't see any way to create a "fixed minimum." I mean, either the target is reached or it isn't. Time elapsed doesn't affect that because time elapsed can't be checked later.

The One

legendary

Activity: 924

Merit: 1000

Quote from: ProfJski on April 20, 2014, 07:14:45 AM

Quote

Plus fixed 1 block per 2 minutes, anyone who finds a block in 1 minute and 59 seconds or less = false. (ie.rejected)

Interesting idea.

The only possible exploit I can think of, is from multi-pools. When the pool finds a coin X block in 1 minute, sit on it, mine something else, do the same if that coin is found early, and then submit at 2 mins exactly. There would be a race condition at 2 minutes, maybe a lot of little block chain forks, so perhaps that's disincentive enough, since if your fork doesn't win, no money.

Can't be done as if you find that block then it would be rejected hence no one can sit on it.

ProfJski

brand new

Activity: 0

Merit: 0

Quote

Plus fixed 1 block per 2 minutes, anyone who finds a block in 1 minute and 59 seconds or less = false. (ie.rejected)

Interesting idea.

The only possible exploit I can think of, is from multi-pools. When the pool finds a coin X block in 1 minute, sit on it, mine something else, do the same if that coin is found early, and then submit at 2 mins exactly. There would be a race condition at 2 minutes, maybe a lot of little block chain forks, so perhaps that's disincentive enough, since if your fork doesn't win, no money.

The One

legendary

Activity: 924

Merit: 1000

Currently 44030

At block 44050 give out an alert warning that there will be a fix.

At block 44100 do the fork. No point in dilly dallying wasting time till block 50,000 or more.

Speed and efficiency gentleman.

Also what about the heartbleed fix?

The One

legendary

Activity: 924

Merit: 1000

Quote from: ProfJski on April 19, 2014, 04:14:54 AM

That was awfully nice of Tranz to offer the fix for free!

Concur.

[/quote]

Pros for 1-block-readjustment:
Gets diff up and DOWN fast.
Should be easy to code, but I have no idea.
Max swing easily fixable in the future if we don't like 11%/20% (Go for 20%, Colin!)
I'm presuming it's less exploitable because it's simpler and clearer.

[/quote]

That what i wanted months ago, no one took my advice.

Plus fixed 1 block per 2 minutes, anyone who finds a block in 1 minute and 59 seconds or less = false. (ie.rejected)

Topic: error - page 25. (Read 360507 times)