M I L L E N N I U M C O I NSaturday Night Bulletin
#3
I've been occupied with the stealth address integration
and modifying it to suit our purposes. The work is being bogged
down a little by the fact, that at the company where I work,
everyone's on holiday so I need to take up tasks that call for immediate
attention, but that are normally handed by someone else. That
situation will however ease up soon.
So starting next week, I'll be moving on to implement the "Glass
onion" portion of the code. Thanks to the little discussion I had with
Ianshop2010
earlier in the thread, I've been able to sharpen some crucial details in the design. There will be some new changes, and
that's what this post will be mainly about.
If you recall, the basic idea was to allow users to approve or disapprove
vendors by refusing to relay their delegate requests. Ianshop2010 pointed
out that a vendor could just set up delegates of his own, to which I countered
that using same delegates would be less secure than allowing a delegate to
be selected randomly among suitable nodes.
But (I confess!) this answer seemed weak to even myself. A vendor could easily
set up multiple delegates and rotate them, placing extra funds on the active
delegate's if necessary. And the benefits of random delegate selection may
seem to be too meager if they come with prohibitive costs in the form of raised
fees, especially as the stealth addresses provide high level of privacy by
themselves.
So the new design will
1) get rid of the random delegation selection (which is buggy to begin with)
and
2) make "personal delegates" so impractical that vendors need to submit
their orders to the approval of the network in order to conduct business.
This will be realized by the following protocol: After a buyer has made a
purchase, the vendor sends to the network a "global delegate request" that
will be relayed to all nodes. It is a message that contains as payload
the vendor's stealth address plus the fee he is offering. A receiving node
then inspects the stealth address, and then any of the following will happen:
- if the stealth address is not valid, the message will be totally ignored.
- if it belongs to a vendor that is on the nodes "ban list", it will not be
relayed, but the node will keep it on memory.
- if the node thinks the vendor is ok, it will forward the message to other
nodes, and keep it on the memory.
- and if the node is a delegate and thinks the vendor is ok, it will contact
the vendor and the delegate transaction process will start from there. The
first delegate to do this will win the job.
The message will expire after N blocks, and if no delegate has picked up the
offer, the vendor has to try again.
Suppose there has been a global delegate request and a delegate has been found.
Then the next thing that the vendor submits to the network, will be the escrow
transaction that will be just as it is today except that hash of the global
delegate request is added to it. Then when this transaction has been received
by a node, any of the following can happen:
- if the hash does not correspond with any of the in-memory global requests,
the transaction will be totally ignored.
- if the hash is found to correspond with a global request belonging to a vendor
on the ban list, it will be totally ignored too, and both the request and the
escrow transaction are erased from that node's memory.
- if the hash corresponds to a request that the node is OK with, the escrow
transaction will be relayed and eventually it gets included to a block.
The upshot is that it is not practical for vendor to bypass the network approval,
as he needs the escrow transactions (without which the delegate process won't work)
to be confirmed ASAP. That is, unless he owns 51% of the coins.
The third major change is that I won't be implement the splitting of the delegate
transaction in this release. First off, all the above will be a lot of work to code and
test properly. Secondly, it hardly matters anyway, since the sole reason for the splitting
of the transactions to a rounded amounts is to make tracing payments harder, but
both the vendor and buyer are protected by delegates and stealth addresses and anyone
now knows that a particular transaction pays to who vendor anyway - although his real-life
identity is protected by a (non-static) onion address and stealth address,
while the buyer is protected by delegates in addition to these layers of privacy.
Ok, that was a wall of text, and questions are, as always, not only very welcome
but also very useful to the development, as I hope this post makes clear.
Oh and that crazy opening image is the MIL graphic put through
Google's DeepDreaming code,
just for fun of it.
The new MIL3 logo will of course be, as always, very different.
Love
Yarko