PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Send a file File manager PDF Toolbox Search Help Contact



MAP .pdf


Original filename: MAP.pdf

This PDF 1.4 document has been generated by Writer / OpenOffice.org 3.2, and has been sent on pdf-archive.com on 11/09/2014 at 13:54, from IP address 79.219.x.x. The current document download page has been viewed 534 times.
File size: 157 KB (2 pages).
Privacy: public file




Download original PDF file









Document preview


MAP+
multi-address-payments and variation in Darksend+
Thought on how to harden the DarkSend+ system against attacks (including “Sybil”)
- by droptable -

With the current implementation of DarkSend the mixing process (maintain of ownership) and
the payment process (change of ownership) can be distinguished.
During the mixing process Alice and Bob send funds to a masternode, the funds will be send
to a new address. Which funds now belong to Alice, and which one to Bob is a secret known
by the masternode. But also from the outside it can be said that the new funds belong either
to Alice or to Bob.
No change of ownership happened.
Lets focus now on the Darksend+ implementation of the client software:
The user specifies an amount of Darksend-rounds which the funds have to go thru to be
labeled as “secure”. In other words: Amounts that have reached the threshold will no longer
be mixed.
Which will result in specific pattern:
A user receives funds, it goes thru the mixing rounds and lay there till the funds are spend.
(receiving address → splitting → mixing → laying around → payment address)

And every observer can imply that the next time the funds are moved it will be a payment.
One of the assumptions the “Sybil” attack is based on that no change of ownership occurs,
but if we allow the Software to mix funds beyond the threshold we can use that to disguise
payments using a multi-adress-payment-system (MAP+):
The receiver sends a list of addresses in stead of one. The next time funds above the
security-threshold are send to the masternodes the software changes some of the (self
owned) receiving addresses into addresses controlled by the receiver of the payment.
Since the denominations will be send thru the DarkSend process afterwards – on both sides regardless if payments or actual mixing funds, the pattern described above will no longer
occur.

This leads to another layer of security:
It can no longer be said when the ownership changes.
The amount of the payment can no longer be assumed.
But it also “breaks” the “ahead of time”-advantage of DarkSend+
- a trade-of that should be discussed.
It also needs to give the user more choice:
Should the Software focus ( - focus, not sole - ) on moving funds into the secure state (e.g. 8
rounds) or should the software deliberately send funds into the DarkSend+ process that are
already above the threshold – depending on the requirements the user needs. (GUI-proposal
below)
It is vital to the system that DS+ is used on funds, from time to time, that are already labeled
as “secure” to not make these movement outstanding and therefore assumable payments.
The implementation of multi-address-payments disguised as DS+ rounds would NOT
tackle attacks like “Sybil” completely.
But Sybil and other attacks would loose parts of their underlying assumptions and would
therefore be harder to execute.


MAP.pdf - page 1/2
MAP.pdf - page 2/2

Related documents


PDF Document map
PDF Document know about payment processing ivr solution
PDF Document avantgard insights payment factories liquidity management
PDF Document ijeas0406015
PDF Document trucking info
PDF Document privacy policy v 1 08 1 17 docx


Related keywords