Essentially, I see a huge shift of mining power otherwise, where the first people with quantum ASICs would dwarf all the other hash power combined.
QC efficiency vs cpu efficiency has already been solved. bitcoin mining pools.
QC power is not anywhere close to todays hashpower.
also
because QC (in peoples doomsday scenarios) is dealing with solving a binary logic problem. QC becomes limited to the rules of binary logic to ensure it gets an acceptable result in the end. so d-wave cannot work with its 65,536 combinations. it has to stick to 256 combinations to be compatible. because QC has 4 possibilities instead of 2. it allows it to need less bits to solve problems
2 problems at once of base2(byte) instead of just 1 byte in binary
4 problems at once of base16(hex) instead of just 2 hex in binary
ill explain
and yes its laymens demonstration, not science whitepaper theory so chill out on knitpicksimagine a byte 00000000 (8 switches)
and the puzzle is to get a certain Hex(base16) result
in binary, an asic splits the byte in 2. and allows 4 switches(0000) to work on one result and 4 switches(0000) to work on another result
where one can start at 0 (binary0000 all switches off and then incrementally turn them on) and go up to 16
the other starts at 16 (binary1111 all switches on and then incrementally turn them off) and go down to 0
so say you wanted to get hex 9
it would take the first lot of switches 10 attempts (0
1,1
2,2
3,3
4,4
5,5
6,6
7,7
8,8
9,9
10)
0000(0),0001(1),0010(2),0011(3),00100(4),0101(5),0110(6),0111(7),1000( 8 ),1001(9)it would take the second lot of switches 7 attempts (F
1,E
2,D
3,C
4,B
5,A
6,9
7)
1111(F),1110(E),1101(D),1100(C),1011(B),1010(A),1001(9)however in QC it wont use 4 switches. as the result it would create once going through all the combinations using its 4 switches would result in a base 256 value when converted to binary.
so QC will use 2 switches to stick to a base 16 puzzle allowing for 4 'chances'. where the efficiency is the
where one can start at 0 (QC 00 all switches off and then incrementally turn them on) and go up to 16(hex:F)
the other starts at 16(hex:F) (QC 33 all switches on and then incrementally turn them off) and go down to 0
the other starts at 7(hex:7) (QC 13 ~half switches on and then incrementally turn them off) and go down to 0
the other starts at 8(hex:8 ) (QC 20 ~half switches on and then incrementally turn rest on) and go upto 16(hex:F)
it would take the forth lot of switches, 2 attempts (8
1,9
2)
20( 8 ),21(9)however QC cannot just send its answer "21" into a binary system. it needs to convert it into binary, which takes resources.
which is like saying
binary:
1.switches show 0(0000) and 16(1111)
2. transmit 00001111
which is 0(0000) and 16(1111) as a whole byte
repeat 6 more times(7 total until there is a correct answer) (7x2=
14 processes all together) to get to hex 9
QC:
1.switches shows 0(00) 7(13) 8(20) 16(33)
2.convert 0(00) 7(13) to binary 0(0000) 7(0111)
3.transmit 00000111
which is 0(0000) 7(0111) as a whole byte
4.convert 8(20) 16(33) to binary 8(1000) 16(1111)
5.transmit 10001111
which is 8(1000) 16(1111) as a whole byte
repeat 1 more times(2 total) (2x5=
10 processes all together) to get to hex 9
yes there may be some ways to make it efficient. but due to the limits of a 256 combination logic and requirement of conversion. QC is not working at its full potential by solving binary logic problems.
QC will only be fully beneficial in instances that do not even use binary logic problems