Bitcoin Forum
December 09, 2016, 09:39:41 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Time for another testnet reset?  (Read 3599 times)
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 01, 2011, 08:36:43 PM
 #21

The widespread adoption or merged mining for bitcoin/testnet would solve the problem of volatile difficulty.
But not for people wanting to test mining. Or including weird scripts. Or excluding weird scripts. Or maybe the people sending weird scripts will hardly ever get them accepted.

1481319581
Hero Member
*
Offline Offline

Posts: 1481319581

View Profile Personal Message (Offline)

Ignore
1481319581
Reply with quote  #2

1481319581
Report to moderator
1481319581
Hero Member
*
Offline Offline

Posts: 1481319581

View Profile Personal Message (Offline)

Ignore
1481319581
Reply with quote  #2

1481319581
Report to moderator
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- gmaxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481319581
Hero Member
*
Offline Offline

Posts: 1481319581

View Profile Personal Message (Offline)

Ignore
1481319581
Reply with quote  #2

1481319581
Report to moderator
1481319581
Hero Member
*
Offline Offline

Posts: 1481319581

View Profile Personal Message (Offline)

Ignore
1481319581
Reply with quote  #2

1481319581
Report to moderator
Disposition
Full Member
***
Offline Offline

Activity: 122


View Profile
November 04, 2011, 08:09:44 PM
 #22

Three proposed changes to simulate testnet to what the Future for Bitcoin will look like.

  • Fixed Difficulty/Fast Adjusted Difficulty as in the future I do not suspect difficulty to change too much. e.g. controlled environment.
  • No BTC generated per block like in the future, block are mined purely for quickly confirming/verifying transactions.
  • 21 Million testnet BTC generated in Genesis Block, emulating the future of circulation, transfer to faucet.

This will make testing much faster,
one can fire up miner, point to testnet,
request coins from faucet, proceed to test,
send coins back, shut off miner.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 23, 2011, 01:25:43 AM
 #23

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).

How often do you get the chance to work on a potentially world-changing project?
SomeoneWeird
Hero Member
*****
Offline Offline

Activity: 700


View Profile
November 23, 2011, 01:36:56 AM
 #24

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).


+1
jojkaart
Member
**
Offline Offline

Activity: 97


View Profile
November 23, 2011, 04:16:06 PM
 #25

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).


How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block. This would also mean that miners should remember the best block they've made so far. It might end up being the one that gets accepted.

However, this sounds like it would be exploitable since the timestamp for a block can be quite a bit in the past.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 23, 2011, 07:18:24 PM
 #26

How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block.

Why?  What problem would that solve?

How often do you get the chance to work on a potentially world-changing project?
jojkaart
Member
**
Offline Offline

Activity: 97


View Profile
November 23, 2011, 07:36:53 PM
 #27

How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block.

Why?  What problem would that solve?


If you intend this feature to stay with testnet, what you suggested is probably fine. However, dropping difficulty sharply to the minimum would result in quite a flood of blocks competing with each other. Scaling the difficulty down slowly would reduce that a lot.

pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
November 23, 2011, 08:35:25 PM
 #28

And just to be clear, this rule will fork the test blockchain between those running on the current or prior versions of the client, and those running on whatever version this change comes out in, right?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 23, 2011, 09:01:58 PM
 #29

And just to be clear, this rule will fork the test blockchain between those running on the current or prior versions of the client, and those running on whatever version this change comes out in, right?

Yes.

Any opinions on whether to do a hard reset (new genesis block with the new rules) or a split ("new rules apply to blocks with timestamps after XYZ") ?


RE: scaling down difficulty:  good idea if we were thinking of implementing something like this for the main network.  But I'd want to give everybody lots of time to think long and hard about potential hacks/exploits/unintended consequences if this was being considered for the main network-- sudden drops in hashing power is NOT a problem for the main network, so I don't think it is worth considering now.

How often do you get the chance to work on a potentially world-changing project?
dree12
Legendary
*
Offline Offline

Activity: 1232



View Profile
November 23, 2011, 10:30:27 PM
 #30

Is there a way to make sure people don't just modify timestamps to get extra coins? I'm sure I'm missing something, but I can't quite see what it is.
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 23, 2011, 10:43:25 PM
 #31

to get extra coins?
This is the testnet we're talking about… coins on the testnet have no value…

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 24, 2011, 02:28:53 AM
 #32

Yes, who cares if you get extra testnet coins?

But... if somebody wanted to be annoying, they'd pre-generate as long a min-difficulty coinbase-only-transaction chain as the block timestamp rules allowed, and constantly broadcast those blocks.  Just to prevent transactions from getting confirmed.

To prevent that...

Testnet could prefer to build on blocks with more transactions from the memory pool over blocks with fewer transactions from the memory pool (that's not a bad rule for main net, either; might be worth considering if it works well for testnet). The rule now is "build on first valid block seen".

And "discourage" (refuse to directly build on or relay) blocks with timestamps in the future.

How often do you get the chance to work on a potentially world-changing project?
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 24, 2011, 05:24:53 AM
 #33

Is testnet trolling really an issue at the moment? I could imagine no one will really bother, since the worst thing you'll cause us mild  annoyance. Testing a feature for mainnet may be a worthy goal though.

About the suggestion itself: I believe it would open the doors for a new kind of attack. If you have ten prevent of the hashing power, but include loads of phoney transactions in your generated blocks, you might still take over the blockchain, depending on the exact implementation.

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 05, 2011, 10:07:24 PM
 #34

https://github.com/bitcoin/bitcoin/pull/686

Testnet difficulty calculation changes, to take effect Jan 1 2012

Allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block.
Normal rules apply every 2016 blocks, though, so there may be a very-slow-to-confirm block at the difficulty-adjustment blocks (once per month, assuming testnet is in it's normal "difficulty too high for number of people mining it" state).

This will almost certainly cause a testnet blockchain split after Jan 1. After pulling I'll update the Testnet Faucet, I'll ask theymos if he can update the testnet block explorer bitcoind.

I didn't implement any "shun blocks from the future" or "prefer blocks with more memory-pool transactions", I want to see how well the simplest-thing-that-might-possibly-work solution works first.

How often do you get the chance to work on a potentially world-changing project?
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!