I see. Didn't they "solve" it in I0coin ?doublec wrote:Because anything involving 'real world time' to decide when to change difficulty will be problematic with the different clock times in clients.jtimon wrote: Why don't change the retarget to 2016 blocks or two weeks, whatever happens first?
The "mine a lot a leave" could be considered an attack.
implications of merged mining / shared blockchain
Re: implications of merged mining / shared blockchain
-
- Posts: 149
- Joined: Mon May 23, 2011 12:47 am
- os: linux
- Location: Auckland, New Zealand
- Contact:
Re: implications of merged mining / shared blockchain
They tried, but it is broken. I0coin will likely split when the difficulty changes due to this code unless a fix is made.jtimon wrote: I see. Didn't they "solve" it in I0coin ?
Re: implications of merged mining / shared blockchain
Do the bitcoin developers see this "mine a lot and then leave" as a possible attack?
-
- Posts: 149
- Joined: Mon May 23, 2011 12:47 am
- os: linux
- Location: Auckland, New Zealand
- Contact:
Re: implications of merged mining / shared blockchain
They probably don't consider it since they have a ton of hashing power. It could be a problem though if for some reason people jumped onto another blockchain or 'earn money with your gpu' system.jtimon wrote:Do the bitcoin developers see this "mine a lot and then leave" as a possible attack?
Re: implications of merged mining / shared blockchain
It seems like there should be some way to tell time without using an external time source since one of the tasks of the btc/nmc network is to act as a time-stamping algorithm (this is the concept behind the double-spend solution and what all the hashing is about). It is not a super accurate time source but should be fine to determine if 2 weeks has elapsed or not since the last diff. adjustment.
Re: implications of merged mining / shared blockchain
+1moa wrote:It seems like there should be some way to tell time without using an external time source since one of the tasks of the btc/nmc network is to act as a time-stamping algorithm (this is the concept behind the double-spend solution and what all the hashing is about). It is not a super accurate time source but should be fine to determine if 2 weeks has elapsed or not since the last diff. adjustment.
-
- Posts: 149
- Joined: Mon May 23, 2011 12:47 am
- os: linux
- Location: Auckland, New Zealand
- Contact:
Re: implications of merged mining / shared blockchain
You could probably do it by comparing the time of the most recently solved block to the time of the block where difficulty last changed. If that is greater than 2 weeks then the difficulty changes at the next block.moa wrote:It seems like there should be some way to tell time without using an external time source since one of the tasks of the btc/nmc network is to act as a time-stamping algorithm (this is the concept behind the double-spend solution and what all the hashing is about). It is not a super accurate time source but should be fine to determine if 2 weeks has elapsed or not since the last diff. adjustment.
Re: implications of merged mining / shared blockchain
I agree, but have it so that the difficulty changes say 6 or greater blocks after the block that is greater than 2 weeks to stop any time asynchronous errors or shennanigans from creeping in ... i.e. have a hashed time/date-stamp confirming the 'overdue' diff. adjustment at least 6 deep in the chain.doublec wrote:You could probably do it by comparing the time of the most recently solved block to the time of the block where difficulty last changed. If that is greater than 2 weeks then the difficulty changes at the next block.moa wrote:It seems like there should be some way to tell time without using an external time source since one of the tasks of the btc/nmc network is to act as a time-stamping algorithm (this is the concept behind the double-spend solution and what all the hashing is about). It is not a super accurate time source but should be fine to determine if 2 weeks has elapsed or not since the last diff. adjustment.
-
- Posts: 149
- Joined: Mon May 23, 2011 12:47 am
- os: linux
- Location: Auckland, New Zealand
- Contact:
Re: implications of merged mining / shared blockchain
Or namecoin could use solidcoin's algorithm which seems to be working well.moa wrote: I agree, but have it so that the difficulty changes say 6 or greater blocks after the block that is greater than 2 weeks to stop any time asynchronous errors or shennanigans from creeping in ... i.e. have a hashed time/date-stamp confirming the 'overdue' diff. adjustment at least 6 deep in the chain.
Re: implications of merged mining / shared blockchain
+1doublec wrote:Or namecoin could use solidcoin's algorithm which seems to be working well.moa wrote: I agree, but have it so that the difficulty changes say 6 or greater blocks after the block that is greater than 2 weeks to stop any time asynchronous errors or shennanigans from creeping in ... i.e. have a hashed time/date-stamp confirming the 'overdue' diff. adjustment at least 6 deep in the chain.
was there a vote about merged mining? if not, how who made the decision?