MAP .pdf

File information


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 11:54, from IP address 79.219.x.x. The current document download page has been viewed 735 times.
File size: 157 KB (2 pages).
Privacy: public file


Download original PDF file


MAP.pdf (PDF, 157 KB)


Share on social networks



Link to this file download page



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.


Document preview MAP.pdf - page 1/2

Document preview MAP.pdf - page 2/2

Related documents


map
metapay
becoming bitcoin welcome gift 1
doc5
instructions
instructions2

Link to this page


Permanent link

Use the permanent link to the download page to share your document on Facebook, Twitter, LinkedIn, or directly with a contact by e-Mail, Messenger, Whatsapp, Line..

Short link

Use the short link to share your document on Twitter or by text message (SMS)

HTML Code

Copy the following HTML code to share your document on a Website or Blog

QR Code

QR Code link to PDF file MAP.pdf