Making all clients delegates by default would be a bad idea, becoming a delegate has certain dangers like if the delegate exits explicitly before the transaction to the destination is broadcast, when it runs again it will send the transaction to the destination after the client has retrieved its NUD from the apparently rogue delegate. The client could effectively double its NUD if the delegate is treated carelessly, a high traffic delegate could become very profitable but would also need proper care.
I have observed slightly different behaviour when testing
the Sendbydelegate function. Here is a rundown on my
"experiments"
First it should be noted that there are many ways of using
the anon features. NUD implements many RPC calls, and the
wiki gives a "specification of recommended processing policies"
how two parties can conduct an anon transaction.
Then there is a "Sendbydelegate" button in the wallet and a
corresponding RPC call. Using this sets off a sophisticated mechanism that
tries to automate the processing of anonymous transactions. It is this
latter mode that I've been testing quite a lot.
When Sendbydelegate is called by the sender and a delegate with sufficient funds is found,
the sender and delegate enter into exchange of messages during which they build two transactions,
one is called "
Funded Sender Bind" and the other one "
Funded Delegate
Bind". The outputs of those tx's go to new addresses created by their wallets, i.e.
they look like payments to self, but actually they encode all the necessary
information about the recipient, sender and delegate, their addresses,
the amount sent and what to do if things don't work out... They are entirely
different from the standard bitcoin txs and employ complex sequence of custom
opcodes to work. Much of that deeper stuff is beyond my current level of
learning.
The process of initial negotiation stops with these two tx's, that are then broadcast
and when included in block, the second stage of processing starts. Now money
actually starts to move:
delegate transfers the amount first to recipient and
only afterwards sender transfers the funds to delegate. This obfuscates the
link between the sender and recipient, and when there are many such transactions,
it will be very hard to decipher from inspecting the tx's recording in chain who is sending to whom,
because the "natural order" of transactions has been broken.
Now what happens if either delegate or sender shuts down in the middle
of the processing? It looks like neither of them gains anything, the bound transactions
stay in the pending state. But the details of the anon transactions are kept in
special maps and arrays in the client memory and if client is shut down all that
info is gone, and the processing cannot recommence. I think that the data can be reconstructed
from the bound txs but a mechanism would have to be implemented for that. Instead, there
are two RPC calls that allow the parties to retrieve their NUD,
createtransferexpiry for the sender and
createtransferescrow for the delegate. The former is quite
straightforward as it takes only the sender's bound tx id and sender's address as its
inputs. For the delegate, it is harder as he has to find out in addition to his own bound
tx, the sender's bound tx id and extract "join nonce" (a special integer used for identification
purposes) out of it, and I've had no luck getting it to work. Also, if it is the delegate
that shuts down before committing the transfer, there is nothing to be done, his amount
stays in limbo (but the sender can always retrieve his NUD)
So the delegate really seems to take a risk acting as a middleman. The risk comes
from accidental shutdown and dishonest senders, and because of that, he should be
awarded a percentage of the amount transferred instead of a set fee (currently 0.01 NUD).
This is in nutshell all I've learnt so far, and if someone else has studied the program and
sees any error in my conclusions I'd love to get feedback. NUD is a wonderful and exotic creation
whose workings really are fascinating.
