Topic: Mixed proof-of-work scheme (Read 1351 times)
Digibytes has mixed algorithm too
Hi jl2012, I'm curious to know what are your thoughts today on Myriadcoin?
I don't believe your scheme could really be expected to confer any of its purported advantages, at least in the long run.
Instead, people would simply fabricate an ASIC which implemented all three schemes in equal ratio tiled on the die with nice power gating to take advantage of the uneven power utilization and thermal characteristics. With miners on modern processes its very easy to be thermally limited, so having a bunch of "inactive" area at any time is less of a loss than you might guess. This device will have a large power advantage and a non-trivial initial cost advantage over the parties using cpus/gpus/etc, so the end result would be similar to Bitcoin, though perhaps some small constant factor differences. E.g. an ASIC might only be 10x better than the best commodity solution, instead of 100x better. This might sound good, but since mining naturally tends to low/zero profits, it will tend to drive all the less efficient miners out of business even if the span is only 10x.
The wafer cost and conserved component advantages would be similar to Bitcoin, but the higher NRE costs doing the design and validation for the more complicated masks may result in significantly reduced manufacturing diversity compared to the Bitcoin ASIC ecosystem, but thats perhaps more speculative.
I generally think that it's more useful to think as POW functions as tools for creating machine verifiable expenditures of external scarce resources (read: energy; you can just convert all the materials cost to energy from an an analysis perspective). If a malicious party is willing to nearly match the energy expenditures of the honest parties, they can reorganize history. If they are willing to significantly outspend they can reorganize history substantially and DOS attack/censor. From this perspective its more clear that all POW are roughly equivalent, save for some small factors in how much attacking they get for how much investment. Some efforts to be smart can equally backfire: E.g. a very effective anti-asic change that reduced ASICs to only 10x more cost/power efficient than GPUs would not be a win if it increased NRE enough that the honest users had no ASICs but state-level attackers did— it could have the opposite effect of enabling attackers if complexity and upfront costs prevents the honest miners from getting the most efficient hardware possible.
[I moved this over to the altcoin forum because I expect it to get more interest and discussion here: As you note, _existing_ Bitcoin miners will have no interest in adopting this, so that kills the viability as a soft fork, since soft works are unsafe for the miners unless there is a supermajority adoption. It's actually more interesting as a hard fork. ... But things which are still GPU mined like LTC may be more open to suggestions like yours.]
Instead, people would simply fabricate an ASIC which implemented all three schemes in equal ratio tiled on the die with nice power gating to take advantage of the uneven power utilization and thermal characteristics. With miners on modern processes its very easy to be thermally limited, so having a bunch of "inactive" area at any time is less of a loss than you might guess. This device will have a large power advantage and a non-trivial initial cost advantage over the parties using cpus/gpus/etc, so the end result would be similar to Bitcoin, though perhaps some small constant factor differences. E.g. an ASIC might only be 10x better than the best commodity solution, instead of 100x better. This might sound good, but since mining naturally tends to low/zero profits, it will tend to drive all the less efficient miners out of business even if the span is only 10x.
The wafer cost and conserved component advantages would be similar to Bitcoin, but the higher NRE costs doing the design and validation for the more complicated masks may result in significantly reduced manufacturing diversity compared to the Bitcoin ASIC ecosystem, but thats perhaps more speculative.
I generally think that it's more useful to think as POW functions as tools for creating machine verifiable expenditures of external scarce resources (read: energy; you can just convert all the materials cost to energy from an an analysis perspective). If a malicious party is willing to nearly match the energy expenditures of the honest parties, they can reorganize history. If they are willing to significantly outspend they can reorganize history substantially and DOS attack/censor. From this perspective its more clear that all POW are roughly equivalent, save for some small factors in how much attacking they get for how much investment. Some efforts to be smart can equally backfire: E.g. a very effective anti-asic change that reduced ASICs to only 10x more cost/power efficient than GPUs would not be a win if it increased NRE enough that the honest users had no ASICs but state-level attackers did— it could have the opposite effect of enabling attackers if complexity and upfront costs prevents the honest miners from getting the most efficient hardware possible.
[I moved this over to the altcoin forum because I expect it to get more interest and discussion here: As you note, _existing_ Bitcoin miners will have no interest in adopting this, so that kills the viability as a soft fork, since soft works are unsafe for the miners unless there is a supermajority adoption. It's actually more interesting as a hard fork. ... But things which are still GPU mined like LTC may be more open to suggestions like yours.]
Please keep this discussion purely technical. There is no way in hell that ASIC miners will accept such change.
I am always thinking of a mixed proof-of-work alt-coin. It will involve 2 or more hashing algorithms, let's say SHA and Scrypt. A block will be either SHA or Scrypt, indicated by a new field in the header. There will only be one chain, which means SHA and Scrypt blocks will be linked together (it's like PPC). So the blockchain would look like
The difficulty change is determined separately for each hashing algorithms. For example, the difficulty for SHA mining is determined by the time span of the last 2016 SHA blocks, regardless of the number of Scrypt blocks in between.
Advantage of this system:
1. It's much more resistant to 51% attack as the attacker needs hashing power in multiple algorithms
2. Mining will be much more decentralised. We may use 3 algorithms: a strong Scrypt dedicated to CPU mining, SHA-3 suitable for GPU and FPGA mining, and SHA256 merged mined with bitcoin.
3. Breaking one of the algorithms won't break the system immediately, buying more time for a fix
4. It will also provide a feedback mechanism in case one of the block type is growing too slow or too fast. Jumping between alt-chains has become a big trouble because the difficulty won't decrease before next difficulty change. In the proposed scheme people will jump back when there is a difficulty discount and keep the chain moving.
-------------
Up to now, it's all about a alt-coin. However, I just realize that this could be done in bitcoin, with a soft-fork.
To make this a soft-fork, the backbone is still SHA256, while making some tricks in difficulty and include some extra data in coinbase.
1. Assume that we start with a traditional SHA256 block, with difficulty of z. We require that the next block will be an SHA256 block with difficulty of 2z. (since a higher difficulty is required, it is backward compatible)
2. Now we have a new SHA256 block of difficulty 2z. It correspond to the first SHA block in the previous example with difficulty x. Here we call it block A.
3. Scrypt miners start to build blocks on block A with difficulty y. The block will only contain a dummy coinbase transaction, specifying some outputs he wants. The sum of the outputs must be equal to or less than 50% of current block reward (i.e. 25/2=12.5 for now). Since this block is invalid for existing clients, no real bitcoin is generated in this process. Here we call this block B.
4. After blocks A and B are generated, there will be no restrictions on the hash type. Miners will build on block B.
4a. Scrypt miners will work on difficulty 1.1y. Again, the block will only contain a dummy coinbase transaction
4b. SHA miners will work on difficulty x. To make it backward compatible, the prevblock in header is pointing to the last SHA block (i.e. block A), while he has to put the hash of block B in coinbase. In the coinbase transaction, he has to distributed 50% of the reward to the earliest unpaid Scrypt block (i.e. block B) based on its dummy coinbase transaction. The SHA miner will also process transactions normally, and will keep the fee (*OOPS....I find a problem when I am typing this: what to do when block reward becomes smaller and smaller?)
5. If there is a long consecutive Scrypt chain, SHA miners will work on difficulty 0.5x = z, still backward compatible
6. Everything looks unchanged in the view of old clients, except that new blocks come 50% slower. However, this will be adjusted in the next difficulty change.
------------------
For obvious reasons ASIC miners will not accept a change like this (We might have a very slim but non-zero chance to do this before ASIC arrived and majority of GPU miners thought it was good). So this is a pure technical discussion. Just want to show how flexible the bitcoin protocol is and hope something really useful could be developed with similar schemes.
For *OOPS, we may distribute the fee the Scrypt miners (but it sounds not very fair). Instead of specifying the exact value in the dummy coinbase tx, Scrypt miners will specify the distribution in percentage.
I am always thinking of a mixed proof-of-work alt-coin. It will involve 2 or more hashing algorithms, let's say SHA and Scrypt. A block will be either SHA or Scrypt, indicated by a new field in the header. There will only be one chain, which means SHA and Scrypt blocks will be linked together (it's like PPC). So the blockchain would look like
Code:
SHA->Scrypt->SHA->SHA->SHA->Scrypt->SHA->Scrypt->Scrypt->SHA->............
However, to mine consecutive blocks of the same type, the difficulty will be increased by 10%. On the other hand, the difficulty will be decreased by 10% if it is building on consecutive alternative blocks. In the above example, the difficulty will be:Code:
SHA (diff = x)->Scrypt (diff = y)->SHA(x)->SHA (1.1x)->SHA (1.2x)->Scrypt (0.8y)->SHA (x)->Scrypt (y)->Scrypt (1.1y)->SHA (0.9x)->............
The factor will have upper and lower limits of 1.5 and 0.5.The difficulty change is determined separately for each hashing algorithms. For example, the difficulty for SHA mining is determined by the time span of the last 2016 SHA blocks, regardless of the number of Scrypt blocks in between.
Advantage of this system:
1. It's much more resistant to 51% attack as the attacker needs hashing power in multiple algorithms
2. Mining will be much more decentralised. We may use 3 algorithms: a strong Scrypt dedicated to CPU mining, SHA-3 suitable for GPU and FPGA mining, and SHA256 merged mined with bitcoin.
3. Breaking one of the algorithms won't break the system immediately, buying more time for a fix
4. It will also provide a feedback mechanism in case one of the block type is growing too slow or too fast. Jumping between alt-chains has become a big trouble because the difficulty won't decrease before next difficulty change. In the proposed scheme people will jump back when there is a difficulty discount and keep the chain moving.
-------------
Up to now, it's all about a alt-coin. However, I just realize that this could be done in bitcoin, with a soft-fork.
To make this a soft-fork, the backbone is still SHA256, while making some tricks in difficulty and include some extra data in coinbase.
1. Assume that we start with a traditional SHA256 block, with difficulty of z. We require that the next block will be an SHA256 block with difficulty of 2z. (since a higher difficulty is required, it is backward compatible)
2. Now we have a new SHA256 block of difficulty 2z. It correspond to the first SHA block in the previous example with difficulty x. Here we call it block A.
3. Scrypt miners start to build blocks on block A with difficulty y. The block will only contain a dummy coinbase transaction, specifying some outputs he wants. The sum of the outputs must be equal to or less than 50% of current block reward (i.e. 25/2=12.5 for now). Since this block is invalid for existing clients, no real bitcoin is generated in this process. Here we call this block B.
4. After blocks A and B are generated, there will be no restrictions on the hash type. Miners will build on block B.
4a. Scrypt miners will work on difficulty 1.1y. Again, the block will only contain a dummy coinbase transaction
4b. SHA miners will work on difficulty x. To make it backward compatible, the prevblock in header is pointing to the last SHA block (i.e. block A), while he has to put the hash of block B in coinbase. In the coinbase transaction, he has to distributed 50% of the reward to the earliest unpaid Scrypt block (i.e. block B) based on its dummy coinbase transaction. The SHA miner will also process transactions normally, and will keep the fee (*OOPS....I find a problem when I am typing this: what to do when block reward becomes smaller and smaller?)
5. If there is a long consecutive Scrypt chain, SHA miners will work on difficulty 0.5x = z, still backward compatible
6. Everything looks unchanged in the view of old clients, except that new blocks come 50% slower. However, this will be adjusted in the next difficulty change.
------------------
For obvious reasons ASIC miners will not accept a change like this (We might have a very slim but non-zero chance to do this before ASIC arrived and majority of GPU miners thought it was good). So this is a pure technical discussion. Just want to show how flexible the bitcoin protocol is and hope something really useful could be developed with similar schemes.
For *OOPS, we may distribute the fee the Scrypt miners (but it sounds not very fair). Instead of specifying the exact value in the dummy coinbase tx, Scrypt miners will specify the distribution in percentage.
Jump to: