Re: Bye Bye Grey Goo


In article <123avdgp1phqe2a@xxxxxxxxxxxxxxxxxx>, Christopher Specker
<URL:mailto:speckec@xxxxxxxxxxxxx> wrote:

rhooker123@xxxxxxxxxxx wrote:
Thats pretty much self replication anyway, but the way ants to do.

There are a lot of ants and bees working on the same principle. In the
end its the numbers that make for grey good.

Not quite, ants don't wipe out their own colonies when they're not
actively doing anything else.

The problem with the "One nanobot does everything" approach is that only
one nanobot has to have its control systems damaged in order to cause
runaway self-replication. When you're done with the task at hand, you
have to tell them to self-destruct and hope they were all listening.

By assigning the functions of assembling and resource gathering to
different nanobots, you gain the capability of cutting off the supply of
resources. Regardless of how they're programmed, assemblers would be
incapable of building anything when the feedstock ran dry.
Since the disassemblers wouldn't be capable of self-replication, this
would limit the destructive capabilities of the system.

I like this scheme! It seems to handle a lot of the problems.


Another issue is whether a single set of instructions is broadcast to
all nanobots, or a separate copy has to be produced for each nanobot to
follow.

In the first instance, you should assume that some nanobots just don't
get the new instructions when you reprogram the system. You need a way
to remove or disable the nanobots following the old instructions,
without disabling all the nanobots that are actually doing what you want.
In the second instance, when you stop issuing the old instructions, you
know there are a limited number of copies of the old ones floating
around in the system. If each copy can only be read one time, then
eventually all existing copies of old instructions will be depleted. Of
course, in this case you need something capable of replicating the
instructions, which is why I suggested programmer bots in my earlier
post. Remove the programmer bots, and eventually the system depletes
the copies of old instructions. That's why I previously wanted to wipe
most of the nanobots out between cycles.

No matter what you do, in a chaotic environment beyond a certain
size you can expect to lose some nanobots, even if all your nanobots
do not mutate, and continue to follow whatever instructions they
have received.

If I understand you correctly, the aim is to minimise the number of
lost nanobots, and to ensure that lost ones, no matter how they
credibly mutate, can do as little damage as possible.


Getting back to the grey goo issue, the grey goo problem really consists
of three independent problems.
1) How do your nanobots know when to stop replicating?

This is the equivalent of the cancer problem with cells. As long as
there are resources remaining (and some cancer cells even try to
improve their resource situation) if a simple mutation can occur
which means that a nanobot can ignore instructions to stop
replicating, then you can be sure that sooner or later this mutation
will occur. The other issue is a communication failure where the
nanobot has not mutated, but just doesn't get the 'stop replicating'
instruction.

In colonies of cells one technique to avoid cancer, apart from
resource limitation, is that the cells die if they 'get lonely';
unless they continually receive 'stay alive' instructions from
surrounding cells they die (a bit like the 'Game of Life'). This can
be a solution to disposing of isolated replicators that haven't
mutated, or when something causes a communications failure. The
'stay alive' signal becomes another resource that they need from
their environment.


2) How do you stop the disassemblers when you have all the raw
materials you need?

Disassemblers can be just as hazardous to the environment unless
they are carefully constrained; ensuring that their target is
rigidly constrained and there is a fail-safe way to stop them is
important. Making them dependent on an information resource is a
good idea, possibly both an internal and an external one. You
certainly don't want any escaped disassemblers being capable of
waiting indefinitely, and only constrained by the availability of
the target to disassemble (unless, possibly that target is other
nanbots, see below).


3) How you clean up all those unneeded nanobots afterwards? (The best
way to avoid unintended consequences from leaving nanobots behind is to
leave no nanobots behind.)

I've come across the term 'Green Nanotech' used to describe this.
(It's even possible that I coined it! [grin] I don't know!)

Yes, there will be escaped nanobots in any chaotic environment, but
you do your best to minimise them, in particular in delicate
environments like the insides of the human body. You may even count
them all, and send out specialised retrieval nanobots to track down
and bring back lost ones.

This is one reason that I am unhappy about descriptions of
environments of pervasive nanobots - you need more than one type, in
fact you need a nanobot metabolism or ecosystem, to deal with
mutating nanobots. Admittedly most mutations will just break the
nanobot, but then it needs to be cleared away if there is any risk
that the broken form will have a significant bad effect on its
environment.

It will take quite a lot of effort to get something like this
utility fog metabolism/ecosystem working properly (see the novel
"Diamond Age" with its problems of nanotech 'immune' systems), and
until we do a Green Nanotech approach of removing all nanobots after
they do their job is best.


The first problem could be solved by a mechanical equivalent of
telomeres. Assemblers could be programmed to self-replicate a limited
number of times, with some sort of counter included in the instructions.

For the new assemblers, the counter is reduced by 1, and the active
assembler decrements its own counter after following the instructions.

Immortal cancer cells are those where this mechanism has failed. We
need to ensure that this sort of failure is not likely, and that at
least a second, and preferably a third, failure needs to occur,
before we lose control of self-replication. Resource limitation is
an obvious control mechanism, both raw material and some sort of
information resource needed to allow self-replication to continue.


For the second problem, the disassemblers can simply be reprogrammed to
disassemble other disassemblers. This results in a rapidly shrinking
disassembler population.

I like this!

Do you need to have a mutual disassembly protocol, so that if two
meet they agree which gets to disassemble the other?

And, a disassembler in the process of disassembly is not to be
interrupted?

And if two disassemblers encounter a disassembly target they agree
which one gets to do the job?

Otherwise, they both might start in on each other, and both stop due
to being partly disassembled, leaving unpredictable debris behind,
which may not be easily recognisable as of nanotech origin and thus
needing to be cleaned up. Ditto two trying to disassemble the same
target.

Do the disassemblers recognise only nanobots (disassemblers or
otherwise) as legitimate targets if they are all from the same
'job'?

(A job identifier could be some sort of large (64-bit? 128-bit?),
randomly generated, integer?)


For the third problem, the assemblers can be reprogrammed to build
disassemblers again, and those disassemblers can be given instructions
to eliminate all nanobots other than disassemblers, followed by
dismantling other disassemblers.

How do you handle the problem of the disassemblers knowing when to
switch over? Other nanobots will be in short supply after a while,
but it may take a long time to dispose of all of them.

(Also, presumably you don't give the disassemblers their
instructions until you know the assemblers have made enough of them,
as assemblers will be one of their targets as well!)

Do they have something like a counter, which is incremented every
time they dismantle another nanobot, and decremented if they meet
another disassembler, and when that clock hits zero they start
dismantling other disassemblers? If they encountered an isolated
pocket of another nanobots after they had started dismantling other
disassemblers then this would start incrementing the counter again,
causing them to stop dismantling other disassemblers.

Isolated disassemblers would effectively be immortal, and eventually
all you would have left would be these. I'm not sure what sort of
efforts would be needed to tidy up these. I don't _think_ they can
accumulate too much in the environment, but if they are immortal you
would need to think carefully about their likely failure modes.

These isolated, immortal, disassemblers would either be in the
disassemble other nanobots mode, or the disassemble other
disassemblers mode. Whether they are job-specific is important.

Also, if you attempt to do more nanotech work later, where there are
some of these around, then unless they were job-specific they will
disassemble some of your nanbots. Which wont be too good if you are
using a scheme of counting nanobots out, then counting them back in
again to ensure that you haven't lost any. Incompatible schemes!

If your disassemblers are job-specific then they will accumulate in
the environment after sufficient jobs, as they will ignore ones from
other jobs. This may give another clean-up problem!

--
Rory McLean
rory@xxxxxxxxxxxxxxxxxx


.

Relevant Pages

  • Re: Bye Bye Grey Goo
    ... Since the disassemblers wouldn't be capable of self-replication, ... Another issue is whether a single set of instructions is broadcast to ... all nanobots, or a separate copy has to be produced for each nanobot to ... Assemblers could be programmed to self-replicate a limited ...
    (sci.nanotech)
  • Re: objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!
    ... what to do about a potential bug in objdump for ARM.... ... In general disassemblers are architecture unaware. ... You shouldn't really see any unsupported instructions unless you've used ...
    (comp.sys.arm)
  • Re: To Frank
    ... We can't rely on the various Disassemblers for these problems: ... They are almost all seriously wrong with these instructions, ... which encoding is anything but simple. ... go on searching what might be going on with this... ...
    (alt.lang.asm)
  • Re: Invalid instructions in 64bit code (x86-64/AMD64)
    ... Most disassemblers handle invalid instructions by disassembling "db XX" ... It is wrong to assume a ModR/M byte ...
    (comp.lang.asm.x86)
  • Re: To Frank
    ... Betov wrote: ... We can't rely on the various Disassemblers for these problems: ... They are almost all seriously wrong with these instructions, ... which encoding is anything but simple. ...
    (alt.lang.asm)
Loading