Author Topic: Restarting the Chain  (Read 3492 times)

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Restarting the Chain
« on: February 03, 2015, 12:54:20 PM »
Don't get worried :)

As discussed in the past, except this would be a one off....

Example:

At block 600k the chain will stop.
We then restart the chain and have a genesis block (or whatever) which includes all unspent outputs. Everyone keeps their coins, but the block chain is only a couple of hundred mb? (tbh, not sure how big, unless domob can tell us). We can also include the entire gamestates before block 600k as some file as optional? which could be hashed and verified by some key hardcoded in the client?

The chain now compared to when we started disaster is expanding much slower due to the low amount of players on the map (there was once 50 to 100k hunters)... it should last a long time and probably we would never need to do it again.

Problem - This is a time consuming task.

If you want him to do this, then i would suggest we raise at least 3 BTC for him - if domob thinks this is enough and if he is up for it?

I suggest use Domob's Own Addresses and post here with tx id OR, just pledge your donation and just send when it's time (incase funds aren't reached)

Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | HBkxA5QmYSATFoPN1wFk8eBkgwPpY97Mfu

Total So far =
10k HUCs Me
20k HUCs Dev Fund
BGB ?
« Last Edit: February 17, 2015, 04:16:22 PM by Snailbrain »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #1 on: February 04, 2015, 03:13:01 AM »
I will add donation address soon.

I will Donate 10k HUCs from my Personal Funds.
I think it's also fine to give 20k HUCs from the Dev Fund.

That is 30k HUCs.

This would be a very good way of making Huntercoin accessible for New Players.

The client/chain could easily be included with MM client etc.

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
Re: Restarting the Chain
« Reply #2 on: February 04, 2015, 05:21:25 AM »
Agreed, this is a huge hurdle for new players. I'll send some in game HUC or other when the address is available.

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Restarting the Chain
« Reply #3 on: February 04, 2015, 10:10:02 AM »
is this the way you want to implement the pruning thing?
think about it carefully, e.g. instead of replacing all 600k of chain, consider last 590k or something like that to prevent problem of fork/reorg and implement it so that it can be automatically be repeated over time, without the need to generate pruning?
« Last Edit: February 04, 2015, 10:12:14 AM by Mithril Man »
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

domob

  • Developer
  • Sr. Member
  • *****
  • Posts: 284
    • View Profile
Re: Restarting the Chain
« Reply #4 on: February 05, 2015, 06:20:18 AM »
I suggest a slightly changed variant:  Allow the client to run without storing the first N blocks, where N could even be configurable.  With this, I could produce a blockchain download that is fully functional but only includes blocks starting from some initial height (e. g., 500k).  This would also not introduce any changes at all to the network rules and others who want to continue running their "full" client.  The effect should be the same.
Use your Namecoin-ID as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | HBkxA5QmYSATFoPN1wFk8eBkgwPpY97Mfu

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Restarting the Chain
« Reply #5 on: February 05, 2015, 09:38:12 AM »
I suggest a slightly changed variant:  Allow the client to run without storing the first N blocks, where N could even be configurable.  With this, I could produce a blockchain download that is fully functional but only includes blocks starting from some initial height (e. g., 500k).  This would also not introduce any changes at all to the network rules and others who want to continue running their "full" client.  The effect should be the same.

this sounds good, how would you manage utxo with this? i mean for rescan, would you include all UTXO there too i imagine
this, coupled with a command that generate that "snapshot" could be the thing we need
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

domob

  • Developer
  • Sr. Member
  • *****
  • Posts: 284
    • View Profile
Re: Restarting the Chain
« Reply #6 on: February 05, 2015, 01:18:10 PM »
I suggest a slightly changed variant:  Allow the client to run without storing the first N blocks, where N could even be configurable.  With this, I could produce a blockchain download that is fully functional but only includes blocks starting from some initial height (e. g., 500k).  This would also not introduce any changes at all to the network rules and others who want to continue running their "full" client.  The effect should be the same.

this sounds good, how would you manage utxo with this? i mean for rescan, would you include all UTXO there too i imagine
this, coupled with a command that generate that "snapshot" could be the thing we need

The UTXO set is kept already and used for tx verification since last summer or so.  Rescanning is a good point - the tx itself could be constructed from the UTXO set, but if a MerkleTx is needed (not sure why, but I think the code works like that) then you need the full blocks.  So maybe rescanning wouldn't work with such a reduced client.  (Or, at least not if your wallet is missing transactions from blocks before your cut-off.)
Use your Namecoin-ID as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | HBkxA5QmYSATFoPN1wFk8eBkgwPpY97Mfu

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #7 on: February 11, 2015, 01:37:37 PM »
I think -- if we implement this - we should consider reducing block times to 30 seconds... (and all the necessary bits which go with it)

obviously needs LOTs of thought.

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Restarting the Chain
« Reply #8 on: February 11, 2015, 04:18:43 PM »
tx verification takes time, gamestate generation too, with more players, more tx will have to be verified, and reorg could be even a bigger issue . people could even wait 3 blocks before seeing their moves accepted, technically from a gameplay perspective the game time should be increased to allow the execution of a move being executed the next block (of course this would slow down the game too much)
I think that lowering blocktime so much could be technically dangerous
even 45 seconds is risky but maybe could be more doable
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #9 on: February 11, 2015, 10:21:30 PM »
tx verification takes time, gamestate generation too, with more players, more tx will have to be verified, and reorg could be even a bigger issue . people could even wait 3 blocks before seeing their moves accepted, technically from a gameplay perspective the game time should be increased to allow the execution of a move being executed the next block (of course this would slow down the game too much)
I think that lowering blocktime so much could be technically dangerous
even 45 seconds is risky but maybe could be more doable

of course needs more thought-- and i raised the issues multiple times to people on bitcointalk

but definetely something to consider and think about the finer points..

inevitably we should be able to have blockchain games running real time using the same technique - but when? (storage space exponentialy increasing, processing power, internet latency?)
 
I don't think it would be "technically dangerous" at 30seconds.. but i could be wrong
Originally we decided on 1 minute as a safe bet, and Mikhail had some security concerns and thought reorgs may cause an issue if we went lower..
I believe all the reorg bug scenarios have been ironed out.. and as long as exchanges don't rely on transactions for X blocks and collected coins are immature for 2 hours or so as they are now, i don't think there would be significant problems.
Also - decreasing block time does not mean doubling the tx. It just means they are spaced out more. of course then people may do more moves (when pvping?) :D also i think the minimum block size is about 400bytes. so that would add up.
We have also seen huntercoin working with >50k hunters on the map (albeit not everyone moving). With new general costs this would be an impossible number to reach,.  I think calculating the game state with a lot less hunters on the map isn't going to make a difference, or at least it will be the same for everyone.

having your tx included in the block is down to the miner,with move fees there is not really any reason they won't start looking to solve the block with your tx included once they receive it.
30 seconds should be ample time and if not, everyone else is in the same boat.
I think, in huntercoins peak (with 50k+ hunters on the map) we reached the block size limit (i think was 1mb, domob would have to confirm), i believe we increased this to 4mb, with movement fees added this reduced the block sizes even more (people weren't moving for no reason), then general cost increase (even less hunters and tx)..

reorgs happen in real life all the time and don't cause much of an issue:
https://www.youtube.com/watch?v=z_KmNZNT5xw
:D

but yep definitely needs more thought and probably won't happen :D - worth thinking about though - maybe if domob gets some time he can do some math :D

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #10 on: February 12, 2015, 12:39:40 AM »
edited OP with donation pledges

domob

  • Developer
  • Sr. Member
  • *****
  • Posts: 284
    • View Profile
Re: Restarting the Chain
« Reply #11 on: February 12, 2015, 07:10:56 AM »
May be related:  I was also thinking about doing a reimplementation of Huntercoin on Namecoin Core.  This should help with enabling pruning, and improve the code, security and performance significantly.  However, of course that's a real lot of work.  Another difficulty is the lack of a cross platform, free UI.  I don't really want to port the existing Qt UI, so would need help from someone to either do that or to implement a fully functional RPC-based UI that is cross-platform.  It definitely needs not be as extensive as MM's client, just enough to use every feature and to test.
Use your Namecoin-ID as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | HBkxA5QmYSATFoPN1wFk8eBkgwPpY97Mfu

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #12 on: February 12, 2015, 09:36:49 AM »
May be related:  I was also thinking about doing a reimplementation of Huntercoin on Namecoin Core.  This should help with enabling pruning, and improve the code, security and performance significantly.  However, of course that's a real lot of work.  Another difficulty is the lack of a cross platform, free UI.  I don't really want to port the existing Qt UI, so would need help from someone to either do that or to implement a fully functional RPC-based UI that is cross-platform.  It definitely needs not be as extensive as MM's client, just enough to use every feature and to test.

that would make sense, as when that time comes, all the time spent on pruning the current chain may be wasted with code differences..?

maybe doing the one off prune with current utxo in genesis block might be best idea until we can get all that stuff done?

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 987
    • View Profile
Re: Restarting the Chain
« Reply #13 on: February 12, 2015, 11:02:41 AM »
if we complete this - i believe it will not only make it more accessible to new players, but also allow exchanges to more easily add Huntercoin.

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Restarting the Chain
« Reply #14 on: February 13, 2015, 05:19:13 PM »
tx verification takes time, gamestate generation too, with more players, more tx will have to be verified, and reorg could be even a bigger issue . people could even wait 3 blocks before seeing their moves accepted, technically from a gameplay perspective the game time should be increased to allow the execution of a move being executed the next block (of course this would slow down the game too much)
I think that lowering blocktime so much could be technically dangerous
even 45 seconds is risky but maybe could be more doable

of course needs more thought-- and i raised the issues multiple times to people on bitcointalk

but definetely something to consider and think about the finer points..

inevitably we should be able to have blockchain games running real time using the same technique - but when? (storage space exponentialy increasing, processing power, internet latency?)
 
I don't think it would be "technically dangerous" at 30seconds.. but i could be wrong


In the future... I think a slow paced RPG could look real time on a 3 second blockchain (if it has 5 second combat animations). The incoming transactions in the mempool are better than any client prediction, everyone knows already what the "game server" knows.

But currently lower block times make inequality between nodes on high-end hardware with fast connection and slow nodes worse.
Players who have to wait 1 block more before seeing their moves accepted will always lose in PvP.